On Tue, Mar 13, 2012 at 7:39 AM, Manik Surtani <manik(a)jboss.org> wrote:
On 8 Mar 2012, at 05:42, Dan Berindei wrote:
> I think a bigger problem is our reliance on AbstractQueuedSynchronizer
> (used by Semaphore as well, btw), which forces us to use a
> thread-local internally.
Yes. I did try and not implement Lock, and pass in the lock owner directly, but a lot of
AQS is private or package-protected and as such can only access an "owner" via a
thread local. The other, other way is to completely re-implement AQS, but that (a) is
non-trivial and error-prone and (b) would need to access JDK unsafe constructs which will
hamper portability.
I found this little gem in the AQS source code:
/**
* Setup to support compareAndSet. We need to natively implement
* this here: For the sake of permitting future enhancements, we
* cannot explicitly subclass AtomicInteger, which would be
* efficient and useful otherwise. So, as the lesser of evils, we
* natively implement using hotspot intrinsics API. And while we
* are at it, we do the same for other CASable fields (which could
* otherwise be done with atomic field updaters).
*/
So it would definitely be possible to re-implement AQS using
AtomicLongFieldUpdater and avoid using Unsafe directly. It still
doesn't mean it's going to be trivial...
Cheers
Dan