[cxx-abi-dev] One-time Construction API (3.3.2)

[Dennis Handly]

>From: Jason Merrill <jason at redhat.com>
>It turns out that checking the guard is broken on the ia-64 platform unless
>there is a memory barrier in the case that 'guard' is set.

>The cheapest workaround is to add memory barriers  ...
>and in the already-initialized path if it reorders loads (Alpha, ia64).

>Unfortunately, pthreads (for instance) don't have a portable way of forcing
>a memory barrier other than with a mutex.

I assume that mutex has a memory fence.

>The simplest fix is just to remove the check in the compiler-generated
>code, but...

No need.  If you have a mutex lock/unlock in the runtime, that would have
to have a memory fence.

>I think I will probably solve this problem by implementing a memory barrier
>primitive in GCC.  What do you do?
Jason

We don't do anything.  But talking with a colleage about a similar
problem of initializing a counter that uses fetchadd, there is no
need to handle the initial store of 0, since the user must have some
type of synchronization that tells another thread it exists.
And we assume that our pthreads library must have memory fences all over
the place.