Subject: Re: [boost] [uuids] generating uuids from multiple threads
From: Michael Marcin (mike.marcin_at_[hidden])
Date: 2009-01-09 19:11:19
Andy Tompkins wrote:
>> I'm not a threading guru but I was under the impression that double-
>> checked locking pattern is dependent on the compiler and processor
>> memory model and not portable.
>> I am guaranteed that my function won't be called before main and no
>> threads are started before main so I think that gives me some leeway
>> for an easier solution.
>> The uuids documentation says:
>> "The boost::uuids::uuid_generator::operator() function returns a random-number-
>> based uuid. The default random number generator is boost::mt19937 from
>> the Boost Random library. It is seeded with a SHA-1 hash of a number
>> of different values including std::time(0), std::clock(),
>> uninitialized data, value return from new unsigned int, etc.."
>> I'm not sure if this means I can expect to create a uuid_generator on
>> the stack and get a uuid A and then create a uuid_generator on the
>> stack and get uuid A != B. It seems to be that if somehow thread id or
>> processor id was also used to create the seed the value I could do
>> this and avoid any shared state and locking.
> It is expensive to create a boost::uuids::uuid_generator compared to
> generating a uuid from it. If you are creating lots of them, you may
> not want to create a generator every time you need to create a uuid.
> You can expect that different uuid_generators will produce different
> uuids, but it is possible that they will not. This is not likely
> since it is likely that they will be seeded with different seeds.
> This could be a good solution for you, that is create one
> uuid_generator per thread.
How expensive is it in terms of memory to store a static or thread local
uuid_generator for the length of the program? I only expect this to be
called maybe twice. The application will run on memory constrained
Of course if the code I make is not correct optimizing for size or speed
-- Michael Marcin
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk