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

Ron Pressler ron.pressler at gmail.com
Sun Jun 30 02:03:03 EDT 2013


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130630/a6c103a8/attachment.html>


More information about the Concurrency-interest mailing list