[infinispan-dev] Semaphore vs Lock

[Dan Berindei]

On Tue, Mar 13, 2012 at 7:39 AM, Manik Surtani <manik at 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