Florian Weimer via Libc-alpha <libc-alpha@xxxxxxxxxxxxxx> writes:
> To fix this, I think it is sufficient to add a release fence just before
> the second version load in the reader. However, from a C memory model
> perspective, I don't quite see what this fence would synchronize
> with.
AFAIU, it would synchronize with the previous relaxed load as if it were a
release operation. Quoting N2731:
A release fence A synchronizes with an atomic operation B that performs an
acquire operation on an atomic object M if there exists an atomic operation
X such that *X is sequenced before A*, X modifies M , and B reads the value
written by X or a value written by any side effect in the hypothetical
release sequence X would head if it were a release operation.
Where:
- X is the read of the STM-protected data;
- B is the load of the counter for a second time;
Notice that I fixed a typo in the original text that says "A is sequenced before
X". Which is impossible because we would end up with:
Fence A
Operation X
Operation B
Source: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2731.pdf
> And of course once there is one concurrency bug, there might
> be others as well. Do I need to change the writer to use
> acquire-release MO for the version updates?
I don't think this is necessary.
--
Tulio Magno
