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