[concurrency-interest] AtomicReferenceFieldUpdater vs Unsafe

Vitaly Davidovich vitalyd at gmail.com
Mon Nov 28 21:29:56 EST 2011


Hi Hans,

In your example why do you say that x should be 17 (or rather, why would
someone assume that)? If thread one writes to x but gets descheduled before
locking, then clearly thread 2 is not guaranteed to read 17; how is this
different from if instead of using a lock, a volatile y was used?

If thread 1 did lock before tryLock in thread 2 then the store to a
volatile inside lock and a read of that volatile in tryLock should be
sufficient to create the happens-before edge.

I must be missing your point though.

Thanks
On Nov 28, 2011 8:23 PM, "Boehm, Hans" <hans.boehm at hp.com> wrote:

> > 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
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20111128/1cc08b43/attachment.html>


More information about the Concurrency-interest mailing list