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
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Mon, 25 Jan 2010 16:05:52 -0600 (CST)
This archive was generated by hypermail 2.1.8 : Tue Jan 26 2010 - 04:15:02 EET