Memory barrier for fat initialization
tg at gmplib.org
Tue Jan 13 14:54:42 UTC 2015
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
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.
Please encrypt, key id 0xC8601622
More information about the gmp-devel