[concurrency-interest] AtomicReferenceFieldUpdater vs Unsafe

David Holmes davidcholmes at aapt.net.au
Mon Nov 28 21:39:39 EST 2011


Vitaly,

Thread 2 only reads x if the lock is not available, which means thread 1
must have locked it, which occurs after setting x=17.

However in terms of happens-before, there is no HB edge here so no guarantee
of x being 17 AFAICS. Thread 2 has to acquire the lock after thread 1 to get
a HB edge that guarantees x == 17. Further, roach-motel tells us that x=17
could be reordered with the lock() anyway.

David
  -----Original Message-----
  From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Vitaly
Davidovich
  Sent: Tuesday, 29 November 2011 12:30 PM
  To: Boehm, Hans
  Cc: Doug Lea; concurrency-interest at cs.oswego.edu
  Subject: Re: [concurrency-interest] AtomicReferenceFieldUpdater vs Unsafe


  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/20111129/ca480d5e/attachment.html>


More information about the Concurrency-interest mailing list