Another idea (not well thought out) would be to try doing something like
threadlets for Java (http://kerneltrap.org/node/7753)
So that some operation would either execute directly, or if a lock is
taken would spawn a thread to wait for access. Not sure if it's a
solution in search of a problem, since I haven't had need to use them
yet, but I thought threadlets and syslets seemed like cool concepts on
their own.
Another structure I've used a lot in UI programming is very similar to
an ExecuterService, except that each task has executeBackground and
exceuteForeground methods. The executeBackground method is called on a
pooled background thread. The executeForground is then called on the
main AWT thread.
--Will
Oliver Zeigermann wrote:
> I was thinking about somthing that implements concurrent collection
> interfaces from j.u.c rahter than using its features, but that might
> be a good idea as well. E.g. What I would like to see would be a
> CopyOnWriteHashMap and - HashSet. Both classes I would have used if
> they existed.
>
> Additionally, classes that help you test concurrent code (which is
> especially tedious and hard to do right) could find their place in
> that component.
>
> Going into detail about the lock manager stuff I was talking about
> would go to far here. Just think of it like something that helps you
> keeping track of all your locks.
>
> Any other ideas?
>
> Oliver
>
> 2007/10/3, Ben Speakmon <bspeakmon@apache.org>:
>
>> Sure. I'd like to hear more about the use cases that demonstrate the need
>> for the components. (Some kind of commons-collections that uses j.u.c would
>> be interesting, for example, since that comes up a lot.)
>>
>> On 10/3/07, Oliver Zeigermann <ozeigermann@apache.org> wrote:
>>
>>> Right. Such a component would contain evertything that is NOT in
>>> j.u.c., but still useful. This means it, it would be an addtion, not a
>>> replacement for j.u.c.
>>>
>>> What could be useful, but is not in j.u.c is subject to discussion.
>>> This might be stuff that is NOT YET in j.u.c because exisiting
>>> solution do not have the quality to go there, yet. Or the scope of the
>>> code is more than general than what is inside j.u.c
>>>
>>> Examples for category I (not mature enough) might be the lock manager
>>> I was talking about. Category II (broader scope) might be the lock
>>> implementation that is geared towards resource locking. Or maybe more
>>> concurrent collections. Or pther special lock implementations. Or
>>> locks with deadlock detections (like in commons transaction).
>>>
>>> Does that make sense?
>>>
>>> Oliver
>>>
>>> 2007/10/3, Ben Speakmon <bspeakmon@apache.org>:
>>>
>>>> My ears prick up at any mention of concurrency!
>>>>
>>>> What's the scope of this, though? With Doug Lea's library, the
>>>> util.concurrent backport, and the JDK 5+ built-ins, what else is needed?
>>>>
>>>> On 10/3/07, Oliver Zeigermann <ozeigermann@apache.org> wrote:
>>>>
>>>>> Folks!
>>>>>
>>>>> I was wondering if anyone would be interested in a component for
>>>>> classes that help you with concurrent programming. An initial
>>>>> contribution could be the locking manager including Lock
>>>>> implementations.
>>>>>
>>>>> Anyone?
>>>>>
>>>>> Cheers
>>>>>
>>>>> Oliver
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
|