[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.
Regards,
Dawid
More information about the Concurrency-interest
mailing list