commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Will Pugh <>
Subject Re: POLL: Anyone interested in a new CONCURRENT component
Date Wed, 03 Oct 2007 21:22:06 GMT
Another idea (not well thought out) would be to try doing something like 
threadlets for Java (

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.


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 <>:
>> 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 <> 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 <>:
>>>> 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 <> 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:
>>>>> For additional commands, e-mail:
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message