From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.lisp.guile.devel Subject: Re: What are the arguments in favor of delay/force in eval.c? Date: Wed, 7 Dec 2005 19:57:58 -0500 Message-ID: <41321ED5-8534-46C0-9A8A-D532203FC8F9@raeburn.org> References: <87hd9mgc7v.fsf@trouble.defaultvalue.org> <87acfcfvbr.fsf@zip.com.au> <87y82wo78b.fsf@trouble.defaultvalue.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1134005096 2072 80.91.229.2 (8 Dec 2005 01:24:56 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 8 Dec 2005 01:24:56 +0000 (UTC) Cc: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Dec 08 02:24:45 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EkAUq-0001l2-U4 for guile-devel@m.gmane.org; Thu, 08 Dec 2005 02:22:57 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EkAV7-0003kt-4i for guile-devel@m.gmane.org; Wed, 07 Dec 2005 20:23:13 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EkA79-00022b-VD for guile-devel@gnu.org; Wed, 07 Dec 2005 19:58:28 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EkA75-0001z9-Eo for guile-devel@gnu.org; Wed, 07 Dec 2005 19:58:27 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EkA73-0001ya-TL for guile-devel@gnu.org; Wed, 07 Dec 2005 19:58:22 -0500 Original-Received: from [216.148.227.153] (helo=rwcrmhc12.comcast.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EkA7z-0002t1-Tg for guile-devel@gnu.org; Wed, 07 Dec 2005 19:59:20 -0500 Original-Received: from raeburn.org (c-65-96-168-237.hsd1.ma.comcast.net[65.96.168.237]) by comcast.net (rwcrmhc13) with ESMTP id <20051208005801015004smege>; Thu, 8 Dec 2005 00:58:02 +0000 Original-Received: from [18.18.1.160] (NOME-KING.MIT.EDU [18.18.1.160]) by raeburn.org (8.12.11/8.12.11) with ESMTP id jB80w0VF008938; Wed, 7 Dec 2005 19:58:00 -0500 (EST) In-Reply-To: <87y82wo78b.fsf@trouble.defaultvalue.org> Original-To: Rob Browning X-Mailer: Apple Mail (2.746.2) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:5491 Archived-At: On Dec 7, 2005, at 17:47, Rob Browning wrote: > { > SCM ans = scm_call_0(SCM_PROMISE_DATA (ans)); > SCM_SET_PROMISE_DATA(p, ans); > SCM_SET_PROMISE_MUTEX(p, SCM_BOOL_F) // (do last to avoid > race at [1]) > result = SCM_PROMISE_DATA(p); > } Of course, the compiler might reorder these accesses, unless you make everything volatile. Even then, the CPU still might reorder them so another compiler might see something different. I'd be worried about the reordering or caching in another processor if the code decides it can bypass all the mutex stuff, too. Once every thread agrees on the new data value and no mutex needed, everything should be fine, but managing the transition to that state (without adding *another* mutex) is very tricky. > scm_unlock_mutex(mutex); That (and the lock call) is probably the only barrier past which you can safely assume that non-volatile accesses won't be reordered. (And for CPU reordering, you probably shouldn't depend too much on simply declaring storage to be volatile. AFAIK most compilers won't insert memory-barrier instructions before and after every volatile access.) Actually, I think some memory models will allow some accesses to be moved into the region where the lock is held from outside it. Ken _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel