From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Dirk Herrmann Newsgroups: gmane.lisp.guile.devel Subject: Re: scm_i_fraction_reduce thread safety Date: Tue, 27 Jan 2004 23:15:39 +0100 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <4016E30B.4060207@dirk-herrmanns-seiten.de> 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> <1074654679.3851.30.camel@flare> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1075241980 17949 80.91.224.253 (27 Jan 2004 22:19:40 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 27 Jan 2004 22:19:40 +0000 (UTC) Cc: Marius Vollmer , guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Jan 27 23:19:28 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 1AlbYI-0005Np-00 for ; Tue, 27 Jan 2004 23:19:28 +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 1AlbY4-0001xg-4Y for guile-devel@m.gmane.org; Tue, 27 Jan 2004 17:19:08 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AlbX2-0001je-3v for guile-devel@gnu.org; Tue, 27 Jan 2004 17:18:04 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AlbVA-00011e-7n for guile-devel@gnu.org; Tue, 27 Jan 2004 17:16:39 -0500 Original-Received: from [212.227.126.171] (helo=moutng.kundenserver.de) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AlbUv-0000fH-Cw for guile-devel@gnu.org; Tue, 27 Jan 2004 17:15:53 -0500 Original-Received: from [212.227.126.179] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1AlbUj-00067l-00; Tue, 27 Jan 2004 23:15:41 +0100 Original-Received: from [80.131.32.124] (helo=dirk-herrmanns-seiten.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1AlbUj-0004Lw-00; Tue, 27 Jan 2004 23:15:41 +0100 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: de, en Original-To: Carl Witty In-Reply-To: <1074654679.3851.30.camel@flare> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:494e3e4d1bf8dc247959c49e6f1f4215 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:3326 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3326 Carl Witty wrote: >On Tue, 2004-01-20 at 16:00, Marius Vollmer wrote: > > >> if fraction is not reduced: >> lock >> if fraction is not reduced: >> reduce it >> unlock >> read it >> >> >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.) > > Interesting - and makes me nervous. If one thread uses the code (set-cdr! pair (cons #t #t)) then this will translate into the writing of three memory locations, namely the car and cdr of the new cell plus the cdr of the old cell. If these write can get arbitrarily re-ordered, then a second thread may access (cdr pair) and find the reference to the new cell, which is not yet initialized. Accessing the uninitalized new cell might lead to a crash of the second thread (I have not thoroughly checked this) . Certainly, this way of accessing memory is wrong, since the user should have done some locking between the two threads. But, (if my assumption is right) the bad thing is, that we are dealing with pure scheme code here, and only the fact that we run the code in a multithreaded environment instead of within a single thread can cause pure scheme code to crash. One might say this is also true for all other kinds of programs when thrown into a multi-threaded environment. But, for guile we had up to now the goal of keeping pure scheme code crash free. The underlying problem here is, that guile's space of cells is actually shared memory between all threads. To make things transparently safe for scheme code would either forbid thread switches to happen at certain points in time (which makes concurrent threads impossible), or to add a lot more locking when accessing the cell space. Am I missing something here? Best regards, Dirk Herrmann _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel