25 Jan
2010
25 Jan
'10
6:44 p.m.
Gabriel M. Beddingfield wrote:
On Tue, 26 Jan 2010, cal wrote:
As I understand it, zyn
wants a reproducible sequence for mainstream,
plus a reproducible per note sequence seeded according to the current
point in the mainstream sequence. Interrupting and resuming the
mainstream sequence was the issue I was looking to simplify. If you step
over srandom_r(), it's really not any great trouble.
.
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.
Probably true, but that's not quite the scenario being addressed.
I saw
potential value in reducing the per note ops going on.
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?
Good question! Some times you simply have to have that little bit of extra
quality of randomness in your life, even if it's just to make you imagine
you feel better.
cheers.