[concurrency-interest] AtomicReferenceFieldUpdater vs Unsafe

Boehm, Hans hans.boehm at hp.com
Mon Nov 28 20:20:31 EST 2011


> From: Doug Lea
> 
> On 11/28/11 14:23, Boehm, Hans wrote:
> > There's another problem with tryLock()-like methods, which I pointed
> out in a
> > 2007 PPoPP paper.  I think the current j.u.c.tryLock() is not
> correctly
> > specified.  The problem is illustrated by the following badly
> designed code:
> >
> > Thread 1: x = 17; l.lock();
> >
> > Thread 2: while (l.tryLock()) l.unlock(); ... x ...  // x should be
> 17 here!
> >
> >
> > A solution, more or less adopted by C++11, is to specify tryLock() as
> > allowing spurious failures,
> 
> I think we are OK on this. The Lock spec defines tryLock in terms
> of the lock being "available", which means different things
> across different Lock implementations, and doesn't rule out
> spurious false returns.
That interpretation sounds good to me.  It does mean that a lock that was constructed before the tryLock call and has never been accessed by anything else might not be "available".

Hans



More information about the Concurrency-interest mailing list