[concurrency-interest] AtomicReference weakCompareAndSet "Mayfailspuriously"?
pete at soper.us
Sun May 28 10:01:37 EDT 2006
Bill Pugh wrote:
> On May 21, 2006, at 6:36 PM, David Holmes wrote:
>> Bill Pugh writes:
>>> I would explain this differently (actually, the JMM requires that
>>> it be explained differently):
>>> weakCompareAndSet has volatile semantics, _except_ that it doesn't
>>> create any happens-before edges.
>> But isn't the existence of those edges the only thing that
>> volatile semantics from non-volatile (barring the 64-bit atomicity
> Nope. Volatile semantics also mean that it it is a synchronization
> that there is a total order over synchronization actions, and that
> each volatile
> read sees the value of the write to that variable that occurred most
> in that total order.
> Plus, the CAS happens atomically (or, for weak CAS, fails spuriously).
So for weak CAS the write is sometimes visible after read, but for
CAS, write visible iff read visible?
That is, given a "visible read" r and a "visible write" w, for CAS w
<==> r but for weak CAS it's w "sometimes after" r. That is, the
visibility of the write of the CAS is stochastic (random), in relation
to the read done by the CAS.
(mostly rhetorical questions)
If I understand this right then I understand your use of "fails" and I
understand the unreliable performance counter that Cliff is yearning
for. I guess the hard part of that API would be the spec? How do you
specify something like this in a way that is crystal clear to all users
or else prevents injury if they shouldn't be using it? "Use of this API
requires certification that you understand Sipser 2nd edition section
0.3 'finding proofs'"? How could we (everybody trying to make Java
better) hope to communicate about visibility of memory operations in a
lowly piece of API javadoc? It's easy to say we'd just leave
"happens-before" out of the weak CAS spec, but that would be like a lion
trap with a sign on the far side that says in an obscure dialect of
Martian "Read this before proceeding. Look down." I guess I'm yearning
for a java.spec.philosophy list.
PS And this clarifies something I'd been pondering lately while blowing
some cobwebs out of my math understanding, which is whether
happens-before is impossible if there is no before or no after. I think
I finally "get it" and there's hope for me properly writing a
topological sort after all. It's been 30 years since Steve Schleimer
(Data General mentor) caused me to wrestle with those and I cried
"uncle" then (American slang wrestling term for "I concede: you won").
PPS This list is fun!
>>> So, here is the question we should discuss:
>>> Should weakCompareAndSet on an AtomicReference create happens
>>> before edges (just as compareAndSwap does)?
>> For consistency I'd say no. Arguably
>> AtomicReference.weakCompareAndSet was a
>> mistake and should be deprecated. But one-in all-in.
>> We probably need to migrate the details from the package docs into the
>> actual method docs.
>> To address Cliff's problem I think the best solution is to add a
>> WeakAtomicInteger class that has no volatile semantics at all. I
>> whether the JMX implementation would benefit from using such a class?
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
More information about the Concurrency-interest