[infinispan-dev] Semaphore vs Lock

[Manik Surtani]

On 13 Mar 2012, at 21:26, Dan Berindei wrote:

> 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…

Yeah I think that would still be a PITA and as discussed earlier, lots of lower hanging fruit.  :)


--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org