David Kastrup <d...@gnu.org> writes:
> It does not appear to me that there is any locking that would prevent
> both ending up with the same random value.
The thread-local 128-bit gensym counters are initialized from
/dev/urandom. The kernel ensures that each `read' gets freshly
generated random bytes, so there's no issue here. According to
Wikipedia, this should cover GNU/Linux, OpenBSD, FreeBSD, NetBSD,
Solaris, Tru64 UNIX, AIX, HP-UX, and MacOS X.
On platforms without /dev/urandom, I have a fallback that uses the time,
date, process ID, and a high-resolution timer if available. In this
case, depending on the resolution of the timers, it is indeed feasible
for two threads to end up with the same seed value, which would be bad.
I think we can solve this problem by including the address of the
scm_i_thread structure into the fallback seed.
Thanks,
Mark
