X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.6 required=5.0	tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,TW_CG,T_TO_NO_BRKTS_FREEMAIL
X-Spam-Check-By: sourceware.org
MIME-Version: 1.0
In-Reply-To: <AANLkTik=xuHN4yO=Zq-W-Rgzvths51scHV3FRjFe7E5N@mail.gmail.com>
References: <AANLkTik=xuHN4yO=Zq-W-Rgzvths51scHV3FRjFe7E5N AT mail DOT gmail DOT com>
Date: Wed, 29 Dec 2010 18:49:28 +0100
Message-ID: <AANLkTinV_3vafKHeLw7eDvaA_8DG7RNJZcW3O-e0sQjW@mail.gmail.com>
Subject: Re: drand48() (and erand48) returns only zeros and pthread application problems
From: =?ISO-8859-1?Q?Jorge_D=EDaz?= <jdzstz AT gmail DOT com>
To: cygwin AT cygwin DOT com, newlib AT sources DOT redhat DOT com
Content-Type: text/plain; charset=ISO-8859-1
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin 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