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: threading issues in 1.8? Date: Wed, 1 Mar 2006 00:17:57 -0500 Message-ID: <31B371FB-C0E1-4F20-8F59-32377DDFADCC@raeburn.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 1141272669 2711 80.91.229.2 (2 Mar 2006 04:11:09 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 2 Mar 2006 04:11:09 +0000 (UTC) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Mar 02 05:11:03 2006 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FEf9X-0003OZ-RI for guile-devel@m.gmane.org; Thu, 02 Mar 2006 05:11:00 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FEf9V-0006MA-Ow for guile-devel@m.gmane.org; Wed, 01 Mar 2006 23:10:58 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FEJit-0003FE-SZ for guile-devel@gnu.org; Wed, 01 Mar 2006 00:18:04 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FEJis-0003Et-Pp for guile-devel@gnu.org; Wed, 01 Mar 2006 00:18:03 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FEJis-0003Ei-8j for guile-devel@gnu.org; Wed, 01 Mar 2006 00:18:02 -0500 Original-Received: from [204.127.192.81] (helo=rwcrmhc11.comcast.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FEJk3-0005bi-Ip for guile-devel@gnu.org; Wed, 01 Mar 2006 00:19:15 -0500 Original-Received: from raeburn.org (c-65-96-168-237.hsd1.ma.comcast.net[65.96.168.237]) by comcast.net (rwcrmhc11) with ESMTP id <20060301051800m1100a0hf4e>; Wed, 1 Mar 2006 05:18:00 +0000 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 k215Hx70006482; Wed, 1 Mar 2006 00:17:59 -0500 (EST) Original-To: guile-devel@gnu.org 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:5749 Archived-At: Hi. I've been starting to look at the 1.8 code, and I'm concerned that there may still be thread safety issues. 1) See my old mail about scm_leave_guile -- in fact, it's now in a comment in threads.c. :-) We're still calling setjmp, returning, and then calling the user's function. I think setjmp and the user's function need to be called from the same function, or at least the function calling setjmp should not return before the user's function is called. (And possibly any args and local variables should be "volatile".) 2) Access to newly created objects: I've been trying to figure out... if one thread allocates a new object (cons cell, say, or vector, or smob), and does a set-car! or something to make it accessible to another thread running on another processor, and the system implements a weak memory order model (so memory writes done without synchronization primitives can be seen as happening out of order), what's to cause the contents of the new pair to get written before the second thread can examine them? Sure, we've more or less adopted the rule that without synchronization, one processor may see the "before" or "after" results of another thread's modifications, or two threads modifying an object may cause it to end up with some unpredictable but valid value. But does that work in the case of a free cell being turned into a cons cell or smob, or random heap storage being turned into a vector? I've been doing a little reading. Not enough to have any answers yet, but enough to see that Java ran into similar issues. Bill Pugh's paper, "Implementing OO Languages under a Weak Memory Order" (http://www.cs.umd.edu/~pugh/java/memoryModel/weak.pdf) discusses much the same issue as was bothering me in Guile -- object initialization in multiprocessor systems with weak memory ordering, particularly on the Alpha. (From other stuff I've read, Alpha seems to provide the weakest coherency model of modern processors, so if we want a robust solution, it pretty much needs to target the Alpha.) His paper is largely about Java, but it seems to me that Guile needs a more precise memory model as well, if it's to be multiprocessor- multithreaded and robust. Unfortunately, I don't follow the Java world closely, but it looks like the revision of the Java memory model and thread spec is worth reading up on. I'm still looking.... Ken P.S. For those not familiar with the Alpha, a tiny bit of background. Digital made some architectural design decisions intended to allow for aggressive performance work. One of them was the weak memory coherency model. The processor has "memory barrier" instructions which can force delayed writes to be performed, or cause changes to main memory by other processors to be seen; naturally, these are somewhat expensive, so you don't want to do them all the time. But without the memory barrier, this sort of situation is *explicitly* permitted in the architecture reference manual: initial state: X=1, Y=1 processor I instruction stream: write X=2, write Y=2 processor J instruction stream: read Y => 2, read X => 1 Even if one processor (not both) uses a memory barrier instruction in between the two operations, the reordered results are allowed. Without a barrier, processor I can perform the second write first, and without a barrier, processor J can perform the second read first. Another interesting change in early Alpha processors was the absence of byte memory I/O operations. (Later processors, since about the EV56, have added them in as an extension.) If you wanted to modify a byte, you'd read the containing 32- or 64-bit word, modify it, and write it back; likewise for 16-bit shorts. There are instructions to provide coordinated changes to specific locations. The "load locked" instructions load a word from storage and "locks" the address; the "store conditional" instruction stores a value if the lock is still set, and sets a flag indicating whether it worked. The lock flag can be reset by various conditions, including other reads or writes from the same processor (I think?), interrupts (including system clock), branches, and writes by other processors to the same location (or within a 2**N block containing it, where the block size is architecture-dependent, but must be at least 16 and no more than one page). If the other processor is using these instructions too, both processors can try to modify a location, but only one (at most) will succeed. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel