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

Hanson Char hanson.char at gmail.com
Sun May 14 23:54:49 EDT 2006


Thanks for explaining.

Does the following code look good to you ?  Is it a good case or "proper"
use of weakCompareAndSet ?
Hanson

public class Foo {
    private volatile int latency = -1;
    private final AtomicInteger maxLatency = new AtomicInteger(-1);

    public void setLatency(int latency)
    {
        this.latency = latency;
        updateMaxLatency(latency);
    }

    private void updateMaxLatency(int latency)
    {
        for (;;) {
            int maxLatencySnapshot = this.maxLatency.get();

            if (latency > maxLatencySnapshot)
            {
                if (this.maxLatency.weakCompareAndSet(maxLatencySnapshot,
latency))
                    return; // new max succesfully set
                // race condition or just fail spuriously; so let's retry
                continue;
            }
            return;
        }
    }
}


On 5/14/06, David Holmes <dcholmes at optusnet.com.au> wrote:
>
>  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.5Javadocs
> > > 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/package-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/61797fdc/attachment.html


More information about the Concurrency-interest mailing list