On Wed, Feb 25, 2015 at 10:35 AM, Ilia Mirkin <[email protected]> wrote:
> 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. > In the dummy function, register pressure was certainly not an issue, but point taken. Still, a compiler barrier prevents reordering like: x = *a; y = *a; pthread_mutex_lock() This changes the external visibility ordering and is certainly NOT ok. However, I contend that it doesn't stop: const int loaded = *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 alone, but I disagree with you. The compiler is under no requirement to reload (*a) because a lock was changed. It does, but it doesn't have to. It's fine if you guys don't want to change it. It may never be a problem with gcc. This is the definition of pthread_mutex_lock() in glibc. There aren't any magic hints that this invalidates memory: extern int pthread_mutex_lock (pthread_mutex_t *__mutex) __THROWNL __nonnull ((1)); THOWNL is attribute((nothrow)).
_______________________________________________ Nouveau mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/nouveau
