[concurrency-interest] AtomicReference weakCompareAndSet "Mayfail spuriously"?

David Holmes dcholmes at optusnet.com.au
Sun May 14 05:14:53 EDT 2006


If it fails it just returns false and doesn't set the value.

The "weak" aspect of this is that it can fail for reasons other than the
current value not matching the expected value. It still has well-defined
behaviour.

If you are interested in the details on platforms that provide load-linked
and store-conditional instructions (ll/sc), these are used to emulate
CompareAndSwap. But a store conditional can fail for reasons other than the
target memory location being written to by some other thread - the
granularity is typically a cache-line, so a write to a close variable can
cause the SC to fail. Even if the same value was written into the variable
the SC would still fail. So typically you use ll/sc in a retry loop until
you either succeed or determine the failure was due to the current value not
being the expected value. This gives you the strong compareAndSet semantics.
The weakCompareAndSet doesn't use the loop.

Cheers,
David Holmes
  -----Original Message-----
  From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Hanson Char
  Sent: Sunday, 14 May 2006 5:05 PM
  To: Doug Lea
  Cc: concurrency-interest at cs.oswego.edu
  Subject: Re: [concurrency-interest] AtomicReference weakCompareAndSet
"Mayfail spuriously"?


  I've gone thru the javadoc, but would like to clarify further.

  In case when the invocation of

    weakCompareAndSet

  does fail, what behavior could we expect from the failure ?

  1) corrupted data being set ? or
  2) runtime exception or error being thrown ? or
  3) the method (weakCompareAndSet) did not set the value but return true ?
or
  4) the method did set the value but return false ? or
  5) the method just failed but the behavior is non-deterministic ?

  Hanson


  On 2/2/06, Doug Lea <dl at cs.oswego.edu > wrote:
    Robert Kuhar wrote:
    > I was strolling through the Docs one day, and came upon the JDK 1.5
Javadocs
    > for Class java.util.concurrent.atomic.AtomicReference.  The
description for the
    > weakCompareAndSet method confuses me:
    >
    >   public final boolean weakCompareAndSet(V expect, V update)
    >
    >   Atomically set the value to the given updated value if the current
    >   value == the expected value. May fail spuriously.
    >
    >   Parameters:
    >     expect - the expected value
    >     update - the new value
    >   Returns:
    >     true if successful.
    >
    > What does "May fail spuriously" mean?  Why would it fail spuriously?
When the
    > spurious failures occur, is the return value always false?  Why would
anyone
    > call this method having been warned that "spurious failure" is
possible?  I
    > think I'm missing something here.
    >

    See

http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/atomic/pac
kage-summary.html

    The javadocs in the atomic package also mention that this form may be
more
    efficient. (At least on some processors; on most (in fact all supported
by
    hotspot) it actually compiles to the same code.) The reason that it may
be more
    efficient is that some processors perform CAS via a pair of Load-linked
/
    Store-conditional instructions, which may fail if some other processor
    happened to write to the same cache line, among other reasons that have
    nothing to do with the CAS. In some cases, this is acceptable. On
    such processors, a full strong CAS must actually be coded internally
    as a loop. There are a handfull of non-blocking algorithms out there
    where you don't actually want that loop, so we include this method
    so you can avoid it. We expect use of this method to be uncommon.

    -Doug
    _______________________________________________
    Concurrency-interest mailing list
    Concurrency-interest at altair.cs.oswego.edu
    http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest


-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060514/6ce89034/attachment.html


More information about the Concurrency-interest mailing list