"Threaded applications should use erand48(), nrand48(), or
jrand48() instead of random() when an independent random number
sequence in multiple threads is required."
So, I would guess that the omission was accidental. For
applications that need to generate random numbers rapidly overhead
of mutual exclusion could be a significant performance limiter. I
don't think that was intended, given the addition of erand48, etc.
Ted
On Tue, Jun 23, 2009 at 11:12:38PM -0400, Stephen Michell wrote:
> They must be reentrant, or rather single threaded or "protected". There
> is global state being maintained here (since random is called with no
> parameters), but if 2 threads were executing code in random, initstate,
> etc. and weren't protected than the seed would be corrupted.
> ...s
>
> Simon Josefsson wrote:
> >All,
> >
> >I'm reading the documentation on
> >
> >http://www.opengroup.org/onlinepubs/9699919799/functions/initstate.html
> >
> >but it isn't clear to me whether the functions are intended to be
> >re-entrant. I'm assuming that is the case because the functions are not
> >mentioned in the list on:
> >
>
>>http://www.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_09_01
> >
> >Do implementations in general provide re-entrant variants of these
> >functions?
> >
> >/Simon
> >
> >
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
|