Memory barrier for fat initialization

[Niels Möller]

tg at gmplib.org (Torbjörn Granlund) writes:

> nisse at lysator.liu.se (Niels Möller) writes:
>
>   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.
>
> How could that happen?  Please elaborate.

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

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.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.