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>
Mon, 30 Mar 2015 05:34:13 +0000 (01:34 -0400)
commite3fa4300bf17d2b051bf21f451656af841404c2b
tree88fd25314e0c37dae2748caec01c47d91fc5ba11
parent02ccece69864c006bafd9c318402195c9d48aa4d
fix missing barrier in pthread_once/call_once shortcut path

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.

(cherry picked from commit df37d3960abec482e17fad2274a99b790f6cc08b)

(edited not to depend on a_barrier, which is not available in 1.0.x)
src/thread/pthread_once.c