On 13 Mar 2012, at 21:26, Dan Berindei wrote: > On Tue, Mar 13, 2012 at 7:39 AM, Manik Surtani <[email protected]> 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 [email protected] twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
