From: Andy (atompkins_at_[hidden])
Date: 2007-06-01 17:04:36
Jos Hickson <jos.hickson_at_[hidden]> wrote in
> On Fri, 2007-06-01 at 17:13 +0000, Andy wrote:
>> "Jos Hickson" <jos.hickson_at_[hidden]> wrote in
>> > On 01/06/07, Dave Jenkins <david_at_[hidden]> wrote:
>> >> Andy,
>> >> You did a nice job speeding up the uuid::create(engine) function
>> >> to 0.4 seconds for 1 million UUIDs. But now the uuid::create()
>> >> function is extremely slow - 131 seconds for 1 million UUIDs
>> >> (source code below). Can you change it to use a static mt19937
>> >> engine?
>> There was opposition to using static objects because of threading
>> concerns. I do want a function that doesn't require the user to
>> create a random number generator themselves.
>> If I use a static engine, I need to protect it with a mutex. This is
>> not optimal because there is the overhead of locking and unlocking
>> the mutex. Some people would rather have a static engine per thread
>> using thread local storage. This still requires one to link with
>> Boost.Thread. I created the uuid::create(Engine) function (great
>> advice from this list) so that users could do whatever they want
>> (static engine per thread, use thread local storage,...).
>> The uuid::create() function should handle the common case and not be
>> best for all situations. So, I guess I need help to determine what
>> the common case is.
> I take it that means that the documentation for uuid::create() should
> have a warning saying "only useful for situation X" or something.
> IMHO the responsibility of a UUID library is to provide the best
> possible UUIDs and if this means having a static without thread
> protection and the warning being about the lack of thread safety then
> I think that is preferable.
Whatever the solution, I will put warnings in the docs where needed. I
do agree that creating better uuids are more important than creating
> I didn't see any of the original reviews but I gather from what you
> said you'd improved that there was some issue about the quality of the
> seeding. If so, then as uuid::create() is the only thing that uses
> the seeding mechanism it would seem strange to put effort into
> improving it if the random number generator is then compromised by the
> repeated reseeding.
> Obviously, though, if the common use case is to only ever create a
> single UUID for the lifetime of an application then it should probably
> stay as it is. FTW I think this is what our most common use case will
> If things are left as they are, however, then it might be useful to
> give a user access to the seeding mechanism you use so that they don't
> need to implement their own if they are going to use the
> uuid::create(Engine) method.
This may be the best solution.
I need to take some time to think about all this. I do want a solution
that works for everyone.
> Otherwise I'd just like to say thanks for the very useful library and
> as we are about to start using UUIDs the timing could not have better!
< snip >
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk