This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: drand48() (and erand48) returns only zeros and pthread application problems
- From: Jorge Díaz <jdzstz at gmail dot com>
- To: cygwin at cygwin dot com, newlib at sources dot redhat dot com
- Date: Wed, 29 Dec 2010 18:49:28 +0100
- Subject: Re: drand48() (and erand48) returns only zeros and pthread application problems
- References: <AANLkTik=xuHN4yO=Zq-W-Rgzvths51scHV3FRjFe7E5N@mail.gmail.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