From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.lisp.guile.user Subject: Re: Some introductory docs about C level threading Date: Tue, 8 Feb 2005 16:45:08 -0500 Message-ID: References: <6b496d191d7216e82df4e9a7afbb3168@raeburn.org> <87fz0falxl.fsf@zip.com.au> <878y61jiuz.fsf@zip.com.au> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1107899160 19614 80.91.229.6 (8 Feb 2005 21:46:00 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 8 Feb 2005 21:46:00 +0000 (UTC) Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Tue Feb 08 22:45:55 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CydBD-0002yE-00 for ; Tue, 08 Feb 2005 22:45:55 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CydPc-0007s5-4k for guile-user@m.gmane.org; Tue, 08 Feb 2005 17:00:48 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1CydNy-0007FN-UE for guile-user@gnu.org; Tue, 08 Feb 2005 16:59:06 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1CydNw-0007Ef-So for guile-user@gnu.org; Tue, 08 Feb 2005 16:59:06 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CydNw-0007EY-M1 for guile-user@gnu.org; Tue, 08 Feb 2005 16:59:04 -0500 Original-Received: from [207.172.4.61] (helo=smtp02.mrf.mail.rcn.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CydAc-0000yR-Ps for guile-user@gnu.org; Tue, 08 Feb 2005 16:45:18 -0500 Original-Received: from 216-15-127-174.c3-0.smr-ubr3.sbo-smr.ma.cable.rcn.com ([216.15.127.174] helo=raeburn.org) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.35 #7) id 1CydAX-00050v-00 for guile-user@gnu.org; Tue, 08 Feb 2005 16:45:13 -0500 Original-Received: from [18.101.0.226] (laptop.raeburn.org [18.101.0.226]) by raeburn.org (8.12.11/8.12.11) with ESMTP id j18LjCLS002111; Tue, 8 Feb 2005 16:45:12 -0500 (EST) In-Reply-To: <878y61jiuz.fsf@zip.com.au> Original-To: guile-user@gnu.org X-Mailer: Apple Mail (2.619.2) X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.user:4223 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:4223 On Feb 6, 2005, at 19:48, Kevin Ryde wrote: > Ken Raeburn writes: >> The problem is, if there are any case where it would be needed, then >> we >> need to use it everywhere there could be a potential problem. >> Depending on just how it works out, that could mean essentially >> declaring some of the scheme object types (like cons cells) as >> volatile, which would be poor for performance. > > I'd think it shouldn't hurt too much. A store written in the code > probably means a store should be done :-). Optimizations for local > variables etc should be unchanged, just memory ops become exactly as > written. And a read becomes a read, with no option for combining multiple reads from the location. I think that's where the performance might not be so good. >> And volatile declarations may fix the possibility of storing >> incomplete >> values, but I don't think it would deal with the cross-thread memory >> access ordering issue. > > I think we have to assume all threads see memory ops in the order > they're done (anything else is too crazy), and with that assumption > and some care libguile ought to be ok. Then you will never have a correct port to the Alpha, at least. The Alpha architecture specification allows for rearrangement of accesses except when a memory barrier instruction is used. (Memory operations issued before the MB must precede those issued after it.) I'd be very surprised if other modern architectures didn't also use various weak memory models, for performance in multiprocessor configurations. _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user