On Thu, 25 Oct 2007 11:09:05 +0200, Thorbjørn Ravn Andersen wrote:
> Oliver Zeigermann skrev den 03-10-2007 22:29:
>> 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.
>>
>>
> You mi
Oliver Zeigermann skrev den 03-10-2007 22:29:
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.
You might find
http://dcl.mathcs.emory.edu/util/backport-util-concurrent/index.php
in
On 10/4/07, Oliver Zeigermann <[EMAIL PROTECTED]> wrote:
> However, this much more looks like what is done in
> commons transaction.
I think you're referring to the Software Transactional Memory research work.
But what about the non-blocking algorithms for concurrent data structures?
I.E., here a
That looks cool. However, this much more looks like what is done in
commons transaction.
Oliver
2007/10/4, Sergio Bossa <[EMAIL PROTECTED]>:
> Hi,
>
> I think that another interesting option would be to do some work on
> non-blocking data structures and algorithms; see the following
> research gr
Hi,
I think that another interesting option would be to do some work on
non-blocking data structures and algorithms; see the following
research group for interesting links and papers:
http://research.sun.com/scalable/
What do you think?
I could make some work on it if there's some interest.
Chee
Oliver Zeigermann wrote:
2007/10/3, Will Pugh <[EMAIL PROTECTED]>:
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
2007/10/3, Will Pugh <[EMAIL PROTECTED]>:
> 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. No
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 proble
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,
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 <[EMAIL PROTECTED]> wrote:
>
> Right. Such a component would
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
solutio
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 <[EMAIL PROTECTED]> wrote:
>
> Folks!
>
> I was wondering if anyone would be intere
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
13 matches
Mail list logo
