Re: Transition to C11 atomics and memory model

[Torvald Riegel <triegel at redhat dot com>]

On Sun, 2014-09-14 at 20:34 +0200, Torvald Riegel wrote:
> 2) Refactor one use (ie, all the accesses belonging to one algorithm or
> group of functions that synchronize with each other) at a time.  This
> involves reviewing the code and basically reimplementing the
> synchronization bits in on top of the C11 memory model.  We also should
> take this opportunity to add any documentation of concurrent code that's
> missing (which is often the case).

While trying to determine what the intended semantics of
atomic_write_barrier are -- it seems to be indeed intended to be a
memory_order_release fence -- I looked at several uses of
atomic_write_barrier.

This wasn't a detailed analysis, but it seems that acquire barriers are
missing in several places:
* nis/nss_nisplus/<several files>  (pthread_once)
* stdlib/msort.c
* malloc/arena.c
* nptl/tpp.c (pthread_once)
* nptl/allocatestack.c
* inet/getnetgrent_r.c (pthread_once)
* include/list.h (concurrent list?)

Those marked with (pthread_once) are, at first sight, incorrect
implementations of exactly-once execution, due to a lack of
atomic_read_barrier / atomic_thread_fence(memory_order_acquire).

For archs with weak memory models like ARM or Power, this can result in
HW race conditions and state corruption.  Even for archs with stronger
models like x86 and SPARC, this can result in state corruption due to
code reordering by the compiler (it's all plain memory accesses, so the
compiler is allowed to assume that this is sequential code, and can
potentially load speculatively or similar).

I also don't remember seeing documentation of the synchronization scheme
in most of these files.

I think this further motivates transitioning to the C11 memory model.