Memory barrier for fat initialization
nisse at lysator.liu.se
Tue Jan 13 13:55:25 UTC 2015
GMP's fat initialization (I'm looking at the x86_64 code now) ends with
*((volatile int *) &__gmpn_cpuvec_initialized) = 1;
I suspect that it's possible (but unlikely) that a different thread on
another cpu may read __gmpn_cpuvec_initialized, get 1, read thresholds
or pointers, and still get old values. I'm about to add fat support to
the nettle library, and to address this, I think I'll replace the
corresponding assignment with
_nettle_synchronous_write (&initialized, 1);
I implement this in the same file as the cpuid function, as
movl %esi, (%rdi)
Does that make sense? I'm not very familiar with these memory model
issues. I don't think the second mfence really is necessary, but it
makes some sense to me to push the new value out to the other cpus as
soon as it's written.
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
More information about the gmp-devel