This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: random, srandom, and initstate
On May 31 15:37, Jeff Johnston wrote:
> On 05/31/2010 05:01 AM, Corinna Vinschen wrote:
> >On May 31 10:36, Corinna Vinschen wrote:
> >>On May 19 13:40, Joel Sherrill wrote:
> >>>(2) Should I go ahead and modify them to be
> >>> the _r versions and have the non-_r version
> >>> call those with static variables?
> >>
> >>Yes. [...]
> >
> >Or, maybe not. Full reentrancy would require to have not only a couple
> >of additional scalar variables in reent, but also to keep the randtbl
> >array reentrant. That's kind of a lot of stuff.
> >
> >Jeff, what do you think?
> >
>
> Assuming we are talking about the glibc _r versions which take a
> struct random_data pointer...
The glibc version is a derivative work based on the BSD version.
Actually we're talking about the BSD version which uses a static
unsigned array to hold the state information, plus 5 or 6 static ints
and pointers, which are not assembled in one struct yet.
> The _r routines will use the struct. AFAICT, the state pointer
> points to an allocated array so modifying the data is ok.
My problem was the default state array called randtbl. This default
state array is not allocated, but static.
My understanding was that the default randtbl should be unique for each
reent entity so that the random number generators in different reent
entities are independent, even when using the default state table.
However, I just examined the glibc implementation. The default randtbl
array is only accessible from the non _r functions and locking just
allows concurrent threads to use the non-_r random functions in
parallel. So my assumption appears to be somewhat over the top.
> The reent struct should have the struct added. It will need
> allocation and initialization for small reent platforms.
Right.
Corinna
--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat