Boost logo

Boost :

Subject: Re: [boost] [xint] Third release is ready, requesting preliminary review
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2010-05-01 12:48:50


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/01/2010 11:59 AM, Christopher Jefferson wrote:
>>> 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.
>
> I assume the thread-unsafety comes from some kind of COW-type
> implementation? std::string in many implementations of standard
> libraries has a similar problem.

That's the largest part of the problem. There's also a random-number
resource that can't safely be used by more than one thread at a time,
but it's only called by a few easily-identifiable functions.

> I don't know about the internals of your library, but would some kind
> of 'remove_sharing', which promised to make an xint not share data
> with any other xint, before I passed it off to another thread, solve
> the problem?

Certainly. There's already such a function there, _make_unique(). As
you'd expect from the name, that ensures that the object in question has
its own storage. So long as it's always called on any integer when it's
passed between threads, there's no danger from multithreaded access. I
didn't think that was worth mentioning though. If you think people would
use it, I'll document it.

> Personally, I often work with multithreaded code nowadays, and would
> prefer not to have to recompile if possible (remember that most
> linux distributions package boost, requiring the library is
> recompiled wouldn't be compatible with such systems.)

I do most of my development under Linux (Ubuntu/Debian). I've found that
the packaged versions of Boost are incomplete, so I have to compile
Boost myself anyway. I don't remember what was missing, but there was at
least one library that I considered pretty commonly used that wasn't
included.

> While this would still require care on the side of users, it would
> solve the problems I personally have. Some might consider it a
> horrible hack of course...

If people don't like it, they can recompile the library with the
thread-safe option and not worry about it. :-)
- --
Chad Nelson
Oak Circle Software, Inc.
*
*
*
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvcW24ACgkQp9x9jeZ9/wQTyACdH4H083iKPqR6CTSOEVkZE1Lq
l8gAoJFQXBz7gcMx8JAMRMsX1/Z97Oox
=Igoa
-----END PGP SIGNATURE-----


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk