This is the mail archive of the gcc@gcc.gnu.org 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 Fri, Aug 14, 2015 at 8:20 AM, Andrey Semashev
<andrey.semashev@gmail.com> wrote:
> On 14.08.2015 13:19, Jonathan Wakely wrote:
>>
>> On 14 August 2015 at 10:54, Andrey Semashev <andrey.semashev@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


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