Memory barrier for fat initialization

Niels Möller nisse at
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 mailing list