25 Jan
2010
25 Jan
'10
6:06 p.m.
On Tue, 26 Jan 2010, cal wrote:
old seed/sequence on every note. I've now got
random_r in
there and I'm comfortable with it, but at this stage I've
no clear indication I've achieved anything valuable or
even better :-).
From 'man 3 random_r':
These functions are the reentrant equivalents of the
functions described in random(3). They are suitable for
use in multithreaded programs where each thread needs to
obtain an independent, reproducible sequence of random
numbers.
That is to say, if you need a reproduceable string of
"random" numbers on each thread (e.g. for unit testing),
then random_r() is your man. Otherwise, it sounds like more
trouble than it's worth.
I.e. if every thread is just doing srandom_r(time(),buf),
it's probably not worth it.
If random() is implemented without memory guards (atomic
ops) on the global variable... then it's possible that
calling random() from two different threads at the same time
could give the same answer -- but so what?
-gabriel