[cfe-commits] patch: libcxxabi cxa_*_virtual and cxa_guard_* methods

[John McCall]

On May 23, 2011, at 4:34 PM, Howard Hinnant wrote:
> My conclusion would have been that the mutex unlock issued after the write to the guard is exactly the write barrier required, and that (on some platforms) the compiler would need to issue a read barrier just before checking the guard (i.e. an atomic read with memory_order_acquire in C++11-speak).

A write barrier *after* the write to _guard isn't good enough.  A
read barrier / write barrier promises that reads/writes (respectively)
executed after the barrier will not be visible out of order with
reads/writes executed before the barrier.  They only actually give
useful ordering guarantees in tandem.

As it stands, there's an unlikely race:

  Thread A writes to _variable.
  Thread A writes to _guard
  Thread B reads _guard, seeing Thread A's write.
  Thread B performs a read barrier.
  Thread B reads _variable, not seeing Thread A's write because
    of the architecture's relatively weak memory ordering.
  Thread A performs a write barrier.

If Thread A now stored something to _foo, and Thread C read from _foo,
saw Thread A's update, and did a read barrier, then Thread C would
be guaranteed to see both of Thread A's earlier stores.  But there's no
analogous promise about Thread B because they haven't "synchronized"
on anything.

John.