> > Gabriel M. Beddingfield wrote: > >> >> 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. >> > 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. > . > >> 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. > >
The placebo randomness affect... Patrick Shirkey Boost Hardware Ltd _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
