Boost logo

Boost :

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(); <snip> Thanks, John. 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() initialization. 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, gregod at, cpdaniel at, john at