On Sun, Feb 3, 2013 at 2:47 PM, David Brown <david.br...@hesbynett.no> wrote:
> On 03/02/13 02:10, Jeffrey Walton wrote:
>>
>> So, it looks like I don't understand sequence points. Please forgive
>> my ignorance.
>>
>> What does C/C++ and GCC offer to ensure writes are complete before
>> reads are performed on a value in a multi-threaded program?
>>
> You are probably looking for a "memory barrier", rather than a "sequence
> point". But even that will not be enough if you have an SMP system - though
> it might let you get better results from your Googling. If possible, your
> best bet is probably to use facilities provided by your OS - but that is
> very much outside the scope of this mailing list.
>
> Anyway, the simplest memory barrier in gcc is :
>
> asm volatile("" ::: "memory");
>
> This tells gcc that memory may be used in unexpected ways at this point in
> the code - so any outstanding writes are handled before this point, and no
> reads are started until after it. But that only applies at the assembly
> code level
Thanks David. That's what I thought (memory barriers and ASM), but I
did not want to taint other's answers, especially since it seemed like
sequence points should have addressed my use cases.
> the compiler does not control things like caches, write
> buffers, read-ahead buffers, etc.
So I am clear: caches, buffers etc are OS - and not CPU caches?
Sorry to ask. I'm trying to figure out (or understand) where the
disconnect occurs between the language and the implementation.
Jeff
