Mark H Weaver <m...@netris.org> writes: > David Kastrup <d...@gnu.org> writes: > >> Mark H Weaver <m...@netris.org> writes: >> >>> Andy Wingo <wi...@pobox.com> writes: >>> >>>> Sorry for asking a stupid question, but why is it that we want the >>>> gensym counter to be thread-local? Just to avoid the mutex? TBH I >>>> don't think it's that big of a point of contention. This risks >>>> devolution into bike-shed-landia tho... >>> >>> It's a reasonable question. I don't feel strongly about it, but I >>> prefer lock-free programming where practical, and in this case there's >>> really no need for coordination between threads. Indeed, these UUIDs >>> are already designed to avoid collisions between multiple _sessions_ >>> without coordination. So why bother with the lock? >> >> To avoid both threads reading the same seed value before generating the >> same number? I have not looked at the code, but that could be a reason >> for serializing. > > Hence the _thread-local_ gensym counters, which is what we're > discussing. Please read before you post.
And there is no problem if one thread initializes its gensym counter from the random source without locking at the same time another thread is in the middle of initializing its gensym counter. It does not appear to me that there is any locking that would prevent both ending up with the same random value. -- David Kastrup
