Ted Baker <baker@cs.fsu.edu> writes:
> "Threaded applications should use erand48(), nrand48(), or
> jrand48() instead of random() when an independent random number
> sequence in multiple threads is required."
I noticed that, but I'm not sure what it implies -- it certainly
provides guidance for programmers to not use random in threaded
applications. But it doesn't say anything explicit about the
(non-)reentrancy of random if a programmer happened to use it despite
the above guidance.
As Stephen suggests, the specification now implies random etc are
re-entrant, so I'm wondering if this is the reality.
/Simon
> 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.
|