Memory barrier for fat initialization
shoup at cs.nyu.edu
Tue Jan 13 21:13:08 UTC 2015
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
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
> 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.
> 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
More information about the gmp-devel