fix missing barrier in pthread_once/call_once shortcut path
authorRich Felker <dalias@aerifal.cx>
Fri, 10 Oct 2014 22:20:33 +0000 (18:20 -0400)
committerRich Felker <dalias@aerifal.cx>
Fri, 10 Oct 2014 22:21:31 +0000 (18:21 -0400)
these functions need to be fast when the init routine has already run,
since they may be called very often from code which depends on global
initialization having taken place. as such, a fast path bypassing
atomic cas on the once control object was used to avoid heavy memory
contention. however, on archs with weakly ordered memory, the fast
path failed to ensure that the caller actually observes the side
effects of the init routine.

preliminary performance testing showed that simply removing the fast
path was not practical; a performance drop of roughly 85x was observed
with 20 threads hammering the same once control on a 24-core machine.
so the new explicit barrier operation from atomic.h is used to retain
the fast path while ensuring memory visibility.

performance may be reduced on some archs where the barrier actually
makes a difference, but the previous behavior was unsafe and incorrect
on these archs. future improvements to the implementation of a_barrier
should reduce the impact.

src/thread/pthread_once.c

index 05ebe69c1f18778554355e62334323a9b70a7cc1..b7388b93ed30e3f6e4f48b75cf60d7696d0eaaab 100644 (file)
@@ -10,8 +10,12 @@ int __pthread_once(pthread_once_t *control, void (*init)(void))
 {
        static int waiters;
 
-       /* Return immediately if init finished before */
-       if (*control == 2) return 0;
+       /* Return immediately if init finished before, but ensure that
+        * effects of the init routine are visible to the caller. */
+       if (*control == 2) {
+               a_barrier();
+               return 0;
+       }
 
        /* Try to enter initializing state. Three possibilities:
         *  0 - we're the first or the other cancelled; run init