[concurrency-interest] Enforcing ordered execution of critical sections?

Doug Lea dl at cs.oswego.edu
Mon Dec 22 19:16:56 EST 2014

On 12/22/2014 03:57 PM, Justin Sampson wrote:

> Is there any way for Semaphore's acquire() to propagate the notification if
> it wakes up and finds not enough permits, at least in the non-fair case?

Not any nice way.

The motivation for bulk-acquire/release methods was to
spare people from needing to write tricky/wrong one-by-one loops.
(For example those that try to acquire n, but if only m<n are
available, release m and maybe try again later.)
The need for them occasionally arises in the classic applications of
semaphores (like counting/controlling the number of available resources).
But we somehow failed to convey that these don't establish a priority
order. We'll fix.

> That is, if the acquire(7) thread gets unparked and sees that there are fewer
> than 7 but more than 0 permits available, can it unpark the next thread
> before parking itself again, so that the next thread can try its acquire(5)?
> In the worst case you end up cycling through all the waiting threads, which
> is nasty, but sounds better to me than deadlocking unnecessarily, and only
> happens when _all_ of the threads are requesting more than 1 permit in
> acquire().
> Of course, that would mean that using Semaphore to implement the
> OrderedExecutor idea in this thread ends up worse than many of the other
> solutions, except for its conciseness. :)

Right. If you want to wake up a lot of threads, it is already simple
enough to use monitor/notifyAll or Condition.signallAll.


More information about the Concurrency-interest mailing list