Re: drand48() (and erand48) returns only zeros and pthread application problems

[Jorge Díaz <jdzstz at gmail dot com>]

About drand48() (and erand48) returns only zeros and pthread
application problems, I send this mail to both cygwin and newlib
mailist.

I have compared Cygwin with FreeBSD function implementation:

  =>  In Cygwin newlib, srand48 and drand48 use "__rand48_seed" and
"__rand48_mult" that are defined as:
                          #define __rand48_seed	_REENT_RAND48_SEED(r)
                          #define __rand48_mult	_REENT_RAND48_MULT(r)
                          #define _REENT_RAND48_SEED(ptr)	((ptr)->_r48->_seed)
                          #define _REENT_RAND48_MULT(ptr)	((ptr)->_r48->_mult)

            where "r" has "_REENT" value, defined as    # define
_REENT (__getreent()) that is a pointer to thread data

      so, in cygwin srand48 and drand48 uses __getreent()->_r48->_seed
  and __getreent()->_r48->_multi  that are thread local variables.

  =>  In FreeBSD libc, last version, srand48 and drand48 use
"_rand48_seed" and "_rand48_mult" that are defined as a global
variable:

            http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/gen/
            http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/gen/_rand48.c

                 unsigned short _rand48_seed[3] = {
                         RAND48_SEED_0,
                         RAND48_SEED_1,
                         RAND48_SEED_2
                 };
                 unsigned short _rand48_mult[3] = {
                         RAND48_MULT_0,
                         RAND48_MULT_1,
                         RAND48_MULT_2
                 };

  =>  As Christopher Faylor said in his mail, I think the solution
would be to modify newlib implementation (files: drand48.c  erand48.c
jrand48.c  lcong48.c  lrand48.c  mrand48.c  nrand48.c  rand48.c
rand48.h  seed48.c  srand48.c) and adapt freebsd last version, using
global variables for seed, mult and rest internal srand48/drand48
variables.

  => This modifications will solve the two problems: lack of seed
initialization and pthread drand48 problems.



On Wed, Dec 29 2010 01:34:18 -0500, Christopher Faylor wrote:
> On Wed, Dec 29, 2010 at 03:47:42AM +0100, Jorge D?az wrote:
> >I am working with cygwin environment (Cygwin 1.7.7 + Newlib 1.18)
> >where drand48 function returns always zero values.
> >
> >The problem was reported in 2004 at cygwin mailist:
> >    1) http://cygwin.com/ml/cygwin/2004-11/msg00488.html
> >    2) http://cygwin.com/ml/cygwin/2004-11/msg00513.html
> >
> >It seems the problem is at drand48 internal initialization. As a
> >workaround if srand48 is called at program beginning, future drand48
> >calls works ok, but this srand48 call is not mandatory.
> >
> >A main problem related with drand48 returning only zeros are cygwin
> >pthread applications that uses drand48:
> >1) We execute srand48 initialization as a workaround of drand48
> >problems in main function.
> >2) After this, if we create several threads, the new threads created
> >in application, has the same zeros problem, but we called srand48 in
> >main function.
> >
> >The application behavior in Cygwin is like every thread has its own
> >"srand48, drand48 and erand48" internal environment and the generated
> >numbers are isolated. In linux and solaris, generated numbers are
> >mixed between all threads.
>
> That is exactly what is happening but, as I noted in the above discussion,
> this behavior is a bug.
>
> I've implemented a workaround which will show up in the next snapshot.
> But, perhaps someone will want to figure out what's wrong with newlib and
> implement a real fix.
>
> I see that freebsd doesn't have this problem so, since that is the code
> base from which the *48 functions are derived, maybe this has actually
> been fixed and newlib could benefit from that.
>
> cgf
>

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple