[cpp-threads] Failed compare-and-swap

[Herb Sutter]

> I completely agree with this.  If a CAS can be used to read the old
> value (which it can, arguably if it only has a boolean result), and it
> has at least acquire semantics, then it should still have acquire
> semantics even if it fails and the write doesn't take place.
> The read still succeeds.
>
> Whether or not it has release semantics is not observable by our
> definitions, since there is no write for another thread to see.  Thus I
> don't think there is any reason to say anything special about that
> either.

Sounds reasonable.

> Trylock is a different situation, since a failed trylock by definition
> reads a value written by an operation (lock acquisition)without release
> semantics.  Thus it currently never establishes a synchronizes with
> relationship, and hence has no impact on visibility.  To meaningfully

Agreed.

> change that, lock acquisition would need release semantics, as it
> technically does in Posix.

I know this was your conclusion in your PPoPP'07 paper. Is that conclusion controversial?

> We've brought this up repeatedly, and I believe there is little support
> for release semantics for lock acquisition, not even from the Posix
> side.

Since your paper, has any consensus emerged on clarifying this in the Posix (or other) spec(s)?

> (I believe a lot of Posix implementations don't follow this
> interpretation of the rules as it stands.)

Is this an impression, or has there been any surveying of real implementations?

> (As Alexander points out, a simple trylock
> can't tell the difference in Posix.  On the other hand, a trylock
> followed by an unrelated successful synchronization operation can.)

Sorry, I missed this. What was the example?

Herb