Re: [boost] [xint] Third release is ready, requesting preliminary review

Subject: Re: [boost] [xint] Third release is ready, requesting preliminary review
From: Vladimir Prus (ghost_at_[hidden])
Date: 2010-05-02 02:55:02

vicente.botet wrote:
> ----- Original Message ----- 
> From: "Chad Nelson" <chad.thecomfychair_at_[hidden]>
> To: <boost_at_[hidden]>
> Sent: Saturday, May 01, 2010 5:18 PM
> Subject: Re: [boost] [xint] Third release is ready, requesting preliminary review
> 
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 05/01/2010 03:32 AM, Marius wrote:
>>
>>>>> I'm happy to announce that the third release of the Extended Integer
>>>>> library is ready, in both the sandbox and the Vault. [...]
>>> Hi, i must say that i'm a bit concerned about making thread safety a 
>>> compile time option especially considering that on unix systems you
>>> don't ussually compile the library and ship it with your program.
>> I see your point, but I don't consider that a major problem. Most people
>> using the library won't need thread-safe operation; the ones that do can
>> compile it themselves with little effort.
>>
>>> And if all the libraries in boost will have compile time options like
>>> that it will quickly become unmanageable for distributions.
>> That's hardly a problem, since "all the libraries in boost" *don't* have
>> that kind of compile-time option. Though several of them already do...
>> just off the top of my head, Boost.Regex requires a compile-time option
>> to support Unicode characters, and I seem to recall several others.
>>
>>> I would suggest that you either make thread safe the default compile 
>>> behaviour
>> That's not really an option, for two reasons: thread-safe behavior is
>> markedly slower, and it has dependencies on Boost.Move (which isn't yet
>> an official Boost library) and Boost.Thread (which, as a compiled
>> library itself, requires linking). The single-thread version is much
>> faster and doesn't require either of those.
>>
>>> or offer both safe and unsafe classes.
>> Certainly possible, though it would complicate the library.
> 
> Couldn't you add a template parameter stating the thread model? This parameter can be by default single_threaded, 
 > and the user can set it also to multi_threaded. In this way you let the user of each xint::integer to decide
 > if the library must ensure thread safety or not.

That does not seem like a great idea. Suppose my application uses a library A that uses library B
that uses library C that uses xint -- and library A uses xint classes in its interface. I certainly
don't want all those libraries to suddely be templated on threading model -- where a library
might not have a single function template in the first place.

Also, why is MT version markedly slower? What, exactly, is the shared data that needs to be
protected in MT case -- it would seem to me that adding a couple of large integers in one
thread is unrelated to multiplying a couple of other interegers in another thread.

- Volodya