On Fri, Aug 14, 2015 at 8:20 AM, Andrey Semashev <andrey.semas...@gmail.com> wrote: > On 14.08.2015 13:19, Jonathan Wakely wrote: >> >> On 14 August 2015 at 10:54, Andrey Semashev <andrey.semas...@gmail.com> >> 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 >> this. >> >> 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.
I believe that you are misunderstanding the "sync" instruction. "sync" does not mean "flush". Thanks, David
