[concurrency-interest] Why can't wait-set Threads be privileged?

Gregg Wonderly gergg at cox.net
Sun Jun 30 23:45:08 EDT 2013


It's easy to add additional signatures for wait/notify to provide additional behaviors.  A List<Thread> could be added as an argument to wait/notify which was used to perform and ordering.  It could be a "queue" that wait enqueued threads to, and that notify peeled off elements from, to wake.  Clearly, you could implement your own such API to behave that way. The larger issue, is what makes sense as a JDK API because it could be tailored for better behavior/performance on different "OSes" vs what makes sense to provide API support for in the JDK so that applications can be more uniformly developed with predictable behaviors.

As a pair, wait/notify are pretty rarely used it seems to me.   I see a lot of wait/notifyAll instead, because most people are trying to use a single object with multiple threads, instead of passing multiple work items off to multiple threads, where a Queue is almost always a better choice with a single thread driving the use of a thread pool so that very little "contention" is actually occurring.

wait/notifyAll creates all kind of contention, and is most often used to "circulate" work amongst a pool of things.  With the queue on wait/notify, you get that behavior (processor/core mobility) without the contention that wait/notifyAll creates.

Gregg Wonderly

On Jun 30, 2013, at 1:03 AM, Ron Pressler <ron.pressler at gmail.com> wrote:

> This is not a technical limitation, but (probably) an API decision.
> 
> Object.wait/notify dates back to Java 1. It was not intended as a low-level synchronization-object-building toolkit, but as a high-level, everyday, bread-and-butter synchronization mechanism. Allowing the programmer to choose which particular thread to wake up doesn't make much sense within those goals.
> 
> j.u.c.locks, however, is a low-level synchronization-object-building toolkit, and you may use it in your hand-rolled constructs to LockSupport.unpark() whichever thread you like.
> 
> On Sun, Jun 30, 2013 at 5:27 AM, thurstonn <thurston at nomagicsoftware.com> wrote:
> So, in java the behavior of Object.wait and Object.notify():
> 
> Thread 1:
> 
> obj.wait() // Thread 1 is put in the wait-set
> 
> Thread 2:
> 
> obj.notify() // Select a Thread from the wait-set and move it to the
> *entry-set*
> 
> 
> 
> What I've always wondered is why there isn't some sort of 'overloaded'
> Object.notify(...) that would essentially do:
> whichever thread is selected from the notify() call, put it at the 'head' of
> the wait-set so that it will enter the monitor next. (Note: what I'm
> suggesting is not the same thing as the 'fairness' parameter to
> ReentrantLock, e.g.)
> 
> Obviously wait() and notify() are native methods, so what I'm wondering is:
> is this a limitation in modern OS's? CPUs?
> 
> I don't know enough about the actual implementation to know what the issues
> are, but this would definitely be a useful feature (think multi-producer,
> single-consumer, etc).
> 
> Of course there are other patterns that you can take to achieve similar
> results, but it would appear to be a lot simpler if you could just specify
> that is the behavior you want in an Object.notify(boolean: privilegewaiters)
> or some equivalent.
> 
> Any insights?
> 
> 
> 
> 
> 
> 
> --
> View this message in context: http://jsr166-concurrency.10961.n7.nabble.com/Why-can-t-wait-set-Threads-be-privileged-tp9808.html
> Sent from the JSR166 Concurrency mailing list archive at Nabble.com.
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> 
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130630/0dd98962/attachment.html>


More information about the Concurrency-interest mailing list