[concurrency-interest] Semaphore doc bug [Was: Enforcing ordered execution of critical sections?]
dl at cs.oswego.edu
Tue Dec 23 06:45:50 EST 2014
On 12/23/2014 01:19 AM, Joe Bowbeer wrote:
> Anyway, I agree it is not clearly stated. I was trying to capture the idea that
> is better illustrated in the example: where releasing 5 permits is not going to
> help if the only thread selected needs 7.
Right. We just need to rule out any interpretation that waiters
are prioritized by counts. There is nothing in any method spec
that supports this interpretation. We had ineffectively discouraged
it by mentioning that bulk-acquire was a "convenience". But without
being explicit, prioritization is only implicitly ruled out,
for example by contemplating the impossibility of being both FIFO
and prioritized in fair mode. And so even experts
can be led to believe that the implementation might be wrong.
Hopefully the doc improvements will prevent this from happening again.
> My interpretation of what Semaphore does is now heavily influenced by what AQS
> supports. I'm glad someone is thinking about what Semaphore *should* do in
> addition to what AQS *can* do.
Completely the opposite. AQS was built to simplify implementation
of a class of synchronizers, but we don't use it when it doesn't
One moral from all this is that we should contemplate
introduction of some kind of priority-based synchronizer.
More information about the Concurrency-interest