commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Will Pugh <willp...@sourcelabs.com>
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 (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


Mime
View raw message