From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Carl Witty Newsgroups: gmane.lisp.guile.devel Subject: Re: scm_i_fraction_reduce thread safety Date: 20 Jan 2004 19:11:19 -0800 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <1074654679.3851.30.camel@flare> References: <3FD85844.3060108@ccrma> <1071170342.1217.60.camel@flare> <87wu91mxhf.fsf@zip.com.au> <87k73z1la9.fsf@zagadka.ping.de> <87ad4ve61r.fsf@zip.com.au> <87hdz3xocn.fsf@zagadka.ping.de> <87zncuat0g.fsf@zip.com.au> <87ektukw66.fsf@zagadka.ping.de> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1074659051 3020 80.91.224.253 (21 Jan 2004 04:24:11 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 21 Jan 2004 04:24:11 +0000 (UTC) Cc: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Jan 21 05:24:02 2004 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1Aj9uM-0003Em-01 for ; Wed, 21 Jan 2004 05:24:02 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1Aj9sV-0007wC-7m for guile-devel@m.gmane.org; Tue, 20 Jan 2004 23:22:07 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1Aj9RO-00026Q-A0 for guile-devel@gnu.org; Tue, 20 Jan 2004 22:54:06 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1Aj9Fe-0007Xa-DV for guile-devel@gnu.org; Tue, 20 Jan 2004 22:42:29 -0500 Original-Received: from [216.254.46.113] (helo=gemini.newtonlabs.com) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1Aj93D-0003gr-Tb for guile-devel@gnu.org; Tue, 20 Jan 2004 22:29:08 -0500 Original-Received: from flare.newtonlabs.com (flare.newtonlabs.com [10.0.0.13]) by gemini.newtonlabs.com (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0L3T2XT008316; Tue, 20 Jan 2004 19:29:02 -0800 Original-To: Marius Vollmer In-Reply-To: <87ektukw66.fsf@zagadka.ping.de> X-Mailer: Ximian Evolution 1.4.3 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:3265 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3265 On Tue, 2004-01-20 at 16:00, Marius Vollmer wrote: > Kevin Ryde writes: > > Yep, though it seems a shame the accessors have to be slowed down just > > so printing and equality can write back. > > Is that slow down significant? The logic could be like > > if fraction is not reduced: > lock > if fraction is not reduced: > reduce it > unlock > read it > > So in the common case of a reduced fraction, no locks would be > necessary. (This works since a fraction can never go from reduced to > unreduced.) I'm afraid this doesn't work. The idiom is known as "double-checked locking"; see http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html for an explanation of why it doesn't work. (Briefly: the "reduce it" code will do something like the following: write numerator, write denominator, write "fraction is reduced" marker. The compiler is allowed to re-order these writes, so the "fraction is reduced" marker is written before the numerator and denominator. Even if it does not, on a multi-processor machine, the memory system may reorder these writes between processors, unless you put (expensive and non-portable) "memory barrier" instructions in the appropriate places.) Read the web page linked above before you suggest ways to fix this. Carl Witty _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel