Re: [LAD] random curiosity

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.

cheers.

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Tue Jan 26 04:15:09 2010