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