[concurrency-interest] AtomicReference weakCompareAndSet "May
fail spuriously"?
Hanson Char
hanson.char at gmail.com
Sun May 14 03:05:17 EDT 2006
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/5ae4e9a8/attachment.html
More information about the Concurrency-interest
mailing list