Memory barrier for fat initialization

[Victor Shoup]

Just to chime in here...

I've recently worked on making some thread safe code,
and learned all about the new memory model in the C11
and C++11 standards (these are thankfully compatible models).
There's lot of stuff online (look for C11 atomics or C++11 atomics,
and buzzwords like memory_order_release).

The point is: this can (in theory) be all done at the C level
in a portable and efficient way...although compilers are 
still playing catchup...but it might be the right way to go
"moving forward"

On Jan 13, 2015, at 4:09 PM, Niels Möller wrote:

> tg at gmplib.org (Torbjörn Granlund) writes:
> 
>> It would not break any language rules, afaik.
> 
> It would break reasonable expectations of threaded programs intended for
> the x86 platform...
> 
>> Before we worry too much, we might want to determine if this could ever
>> be a real problem.  I.e., what happens if only some arbitrary subset of
>> the cpuvec structure is initialised?
> 
> A problematic case is if the sqr_basescasse ptr is initialized, and we
> get an out-of-sync and too large, value for the corresponding threshold,
> which that implementation can't handle. Not sure what other cases there
> are. IIRC.
> 
>> If that's bad, could we *compile*
>> in initial values which are safe, even if some arbitrary values are then
>> modified?
> 
> Sounds doable for the sqr_basecase threshold, at least.
> 
> On the other hand, on x86_64, maybe all chips we care about have the
> needed extensions, so it's *easy* to add an mfence or sfence instruction
> and not have to worry? I guess 32-bit x86 is more painful, since I guess
> we'd have to check if the instructions are available.
> 
> Regards,
> /Niels
> 
> -- 
> Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
> Internet email is subject to wholesale government surveillance.
> _______________________________________________
> gmp-devel mailing list
> gmp-devel at gmplib.org
> https://gmplib.org/mailman/listinfo/gmp-devel