Help needed for glibc software transaction memory algorithm

[Tulio Magno Quites Machado Filho]

Florian Weimer via Libc-alpha <libc-alpha@sourceware.org> 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