[concurrency-interest] Resizing semaphores

Doug Lea dl@cs.oswego.edu
Mon, 3 Nov 2003 09:07:13 -0500

> > Yes, but there is a good compromise available. We could make this (or
> > something with equivalent effect) a protected method that you would
> > need to subclass in order to expose. Good enough?
> That would work well for me.

Done. Spurred by this and other concerns, we also committed some other API
changes for semaphores that we had been contemplating:

* The fair and non-fair variants are merged into a single class with
  fairness constructor param, which is more consistent with how
  fairness is handled elsewhere in j.u.c. Unlike other classes
  though, there is no default fairness setting here, since the
  usage contexts in which you'd want to ensure fairness as opposed
  to achieve higher throughput seem about equally common.
* Permits are now represented as ints, not longs; in part again
  for consistency with how other counts are handled, and in part
  to better equalize expected performance across common platforms.
  These now seem to outweigh overflow concerns.
* There are some new instrumentation methods similar to those
  in ReentrantLock.

As always, comments would be welcome.