search for: __memory_barrier

...*a; x = loaded; pthread_mutex_lock(); y = loaded; Because this doesn't change the external visibility behavior, it just changes whether a value is reloaded. It doesn't break the ordering of a memory barrier at all. > If code like > > x = *a; > pthread_mutex_lock or unlock or __memory_barrier() > y = *a; > > doesn't cause a to get loaded twice, then the compiler's in serious > trouble. Basically functions like pthread_mutex_lock imply that all > memory is changed to the compiler, and thus need to be reloaded. > > Well, I've said before and I might be alo...

So you're saying a compiler can optimize: > > - statement with memory access > - read memory barrier > - statement with memory access > > To drop the second statement? I would worry about your definition of > memory barrier then.. > This is tricky, but I think you're mixing up the general case with the actual code you have. In general, you are pointing to this

On Wed, Feb 25, 2015 at 11:59 AM, Patrick Baggett <baggett.patrick at gmail.com> wrote: >> If code like >> >> x = *a; >> pthread_mutex_lock or unlock or __memory_barrier() >> y = *a; >> >> doesn't cause a to get loaded twice, then the compiler's in serious >> trouble. Basically functions like pthread_mutex_lock imply that all >> memory is changed to the compiler, and thus need to be reloaded. >> > Well, I've said b...

pthread_mutex_lock had *better* imply a compiler barrier across which code can't be moved... which is very different from the printf case where it might have done it due to register pressure or who knows what. If code like x = *a; pthread_mutex_lock or unlock or __memory_barrier() y = *a; doesn't cause a to get loaded twice, then the compiler's in serious trouble. Basically functions like pthread_mutex_lock imply that all memory is changed to the compiler, and thus need to be reloaded. -ilia On Wed, Feb 25, 2015 at 11:28 AM, Patrick Baggett <baggett.patric...

Hey, On 25-02-15 18:05, Ilia Mirkin wrote: > On Wed, Feb 25, 2015 at 11:59 AM, Patrick Baggett > <baggett.patrick at gmail.com> wrote: >>> If code like >>> >>> x = *a; >>> pthread_mutex_lock or unlock or __memory_barrier() >>> y = *a; >>> >>> doesn't cause a to get loaded twice, then the compiler's in serious >>> trouble. Basically functions like pthread_mutex_lock imply that all >>> memory is changed to the compiler, and thus need to be reloaded. >>> &g...