Memory barrier for fat initialization

[Torbjörn Granlund]

nisse at lysator.liu.se (Niels Möller) writes:

  Fat gmp library, cpuvec not yet initialized. Several threads, on
  different cpus, call the CPUVEC_THRESHOLD macro at about the same time.
  
That's the scenario.

  When the first of those threads get to setting
  __gmpn_cpuvec_initialized, the magic that sync caches between the cpus
  happens to propagate the new value of this flag before it has propagated
  the complete contents of the cpuvec. The other thread may then see
  __gmpn_cpuvec_initialized == 1, and invalid thresholds.
  
  I think it's a typical situation that memory barriers are intended to
  address: To enforce the proper ordering, so that no cpu can see the new
  value of __gmpn_cpuvec_initialized without also seeing the new contents
  of cpuvec.
  
My understanding is that the AMD64 as well as older x86 architectures do
not allow store/store reordering, except when explicitly told otherwise.

Since this code is for x86 and AMD64 respectively, we don't need to take
modern, weaker ordered architectures into account here.

If we extend fat binaries to more architectures such as ARM32, ARM64,
and POWER, we will need explicit store reordering instructions, though.

There should be some portable mechansm for this, either as part of some
POSIX standard or within gcc.  I haven't looked into that.

-- 
Torbjörn
Please encrypt, key id 0xC8601622