X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Date: Wed, 29 Dec 2010 01:34:18 -0500 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: drand48() (and erand48) returns only zeros and pthread application problems Message-ID: <20101229063418.GA15320@ednor.casa.cgf.cx> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com 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