Re: [boost] [uuids] generating uuids from multiple threads

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 
mobile devices.

Of course if the code I make is not correct optimizing for size or speed 
doesn't matter.

-- 
Michael Marcin