Subject: Re: [boost] [Review Request] Multiprecision Arithmetic Library
From: Christopher Kormanyos (e_float_at_[hidden])
Date: 2012-04-05 17:48:00
>> I think that's looking OK for threads.
> Actually no, that code *on it's own* is most definitely not thread safe. Anywhere you have a function scope:
> static const UDT my_object.
> where UDT is not a POD, then initialization of my_object is subject to race conditions (in C++03 anyway, C++11 and recent GCC versions get this right I believe).
> What's more if you try to fix the race condition using the "double checked looking idiom", it's still not thread safe, you actually do have to grab a mutex with every call to the function :-(
> However, there's a trick I stole from Boost.Pool employed here, in the:
> constant_initializer<T, &get_constant_e<T> >::do_nothing();
That constant_initializer sure is a nice programming element.
So, let me get this straight. The instantiation of a template such as
get_constant_ln2() causes the compiler to notice that it needs to
instantiate one (and only one) instantiation of template "long_type"::init
in the first translation unit in which it is encountered. C++ has a
one-time deal for template instantiation of non-local class-type statics,
and the thing ends up being initialized once with ctor code in the pre-main()
Is that what you are talking about?
OK. But finally, what if we bombard get_constant_ln2() with an MP
type of run-time dynamic precision, first with 100 decimal digits,
then with 200 decimal digits? Who tells get_constant_ln2() that it
needs to re-calculate ln2? Or is this just a matter of documentation,
saying, in effect, "don't do this!".
Best regards, Chris.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk