Re: [infinispan-dev] Semaphore vs Lock

On Tue, Mar 13, 2012 at 7:39 AM, Manik Surtani <manik(a)jboss.org&gt; 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…