This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [powerpc64le] seq_cst memory order possibly not honored

On 14.08.2015 13:19, Jonathan Wakely wrote:
On 14 August 2015 at 10:54, Andrey Semashev <> wrote:

Otherwise I cannot see how (x==0 && y==0) could happen. The last load in
each thread is sequenced after the first seq_cst store and both stores are
ordered with respect to each other, so one of the threads should produce 1.

The tool evaluates the possible executions according to a formal model
of the C++ memory model, so is invaluable for answering questions like

It shows that there is no sychronizes-with (shown as "sw")
relationship between the seq_cst store and the relaxed load for each
atomic object. There is a total order of sequentially consistent
operations, but the loads are not sequentially consistent and do not
synchronize with the stores.

Thank you Jonathan, you are correct. I've changed the test to use seq_cst on loads as well and also removed the first load as it doesn't really matter for the test. I'll see if it helps the tester.

I'm still not entirely sure if the missing 'sync' instruction is a, let's say, desirable code, from practical point of view. I understand that the seq_cst load will generate an extra 'sync' which will ensure the stored 1 is visible to the other thread. However, if there is no second instruction, i.e. thread 1 performs a store(seq_cst) and thread 2 performs a load(seq_cst) of the same atomic variable, the second thread may not observe the stored value until thread 1 performs another instruction involving 'sync' (or the CPU flushes the cache line for some reason). This increases latencies of inter-thread communication.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]