[concurrency-interest] AtomicReference weakCompareAndSet"Mayfailspuriously"?
dl at cs.oswego.edu
Mon May 29 07:22:07 EDT 2006
To try to extend David's summary into action items:
1. The main use of weakCompareAndSet is for collecting statistics
and the like that don't otherwise interestingly affect the
happens-before orderings of a program. There might also be a few
other niche uses, but none of them involve using it for general
purpose synchronization control. We should add a sentence or two
to Javadocs steering people to use weakCAS only in such cases.
2. The details of the weakCompareAndSet specs need improvement.
Bill: Can you suggest rewordings?
3. As Hans Boehm pointed out, supporting only two flavors
of CAS (compareAndSet and weakCompareAndSet) leaves out the
other two possible orderings. The "missing" methods are:
compareAndSetAcquire that has volatile-read semantics
compareAndSetRelease that has volatile-write semantics
Neither of these appear to be useful if spurious failures are
allowed, so both are "strong" in that sense. It's worth considering
adding them because some processors (PowerPC and Itanium) may
be able to use instructions for them that are cheaper than full
CAS (but usually less cheap that weakCAS). So these would be
the cheapest ways to implement some synchronization algorithms,
and there is no good way to emulate their effects without
using full CAS. (For what it's worth the upcoming C++ spec
will probably distinguish these cases, although with different
details.) On the other hand, usage would be rare and adding yet
more subtly different variants will probably lead to more
confusion. So I'm still unsure about this.
More information about the Concurrency-interest