Re: [boost] [Review Request] Multiprecision Arithmetic Library

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.