[concurrency-interest] Backport limitations

Dawid Kurzyniec dawidk at mathcs.emory.edu
Sat May 13 12:57:00 EDT 2006

Mike Skells wrote:
> Hi
> I noticed (which backporting some code) that the semaphores do not 
> allow for multi acquires
> Is there a specific reason for this is it just lack of dev resources. 
> I use this is current J5 code and I am looking to not try to rewrite 
> that code to do the backport

I have just finished implementing multi-acquires for fair semaphores; 
the code is available in backport CVS and the latest daily build at 
http://dcl.mathcs.emory.edu/util/backport-util-concurrent/. (It passes 
unit tests, but if anybody is able to more thoroughly test it, I would 
appreciate some feedback). For non-fair semaphores, the problem is a bit 
more fundamental. Current implementation of release(n) wakes up exactly 
n threads using notify(). If all of the waiters turn out to be 
multi-acquirers however, it might be the case that all awoken threads 
must go back to sleep, and no thread would proceed at least until next 
notify. Is this acceptable?

An alternative would be to notifyAll(), but it would affect performance 
- using the fair version instead might actually be a better idea.

Thus far, I have taken a conservative approach and left multi-acquires 
for non-fair semaphores unimplemented (UnsupportedOperationException 
thrown from blocking acquire(n) etc if n >= 2). Non-blocking 
tryAcquire(n) works, however.


More information about the Concurrency-interest mailing list