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, 1 Feb 2005 12:37:36 -0500 Message-ID: <6b496d191d7216e82df4e9a7afbb3168@raeburn.org> References: NNTP-Posting-Host: main.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 1107279847 8843 80.91.229.2 (1 Feb 2005 17:44:07 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 1 Feb 2005 17:44:07 +0000 (UTC) Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Tue Feb 01 18:44:07 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Cw247-0000Ng-PD for guile-user@m.gmane.org; Tue, 01 Feb 2005 18:43:52 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Cw2EY-0008Nn-3i for guile-user@m.gmane.org; Tue, 01 Feb 2005 12:54:38 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Cw2E6-0008Ic-Mq for guile-user@gnu.org; Tue, 01 Feb 2005 12:54:11 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Cw2E1-0008Fa-1T for guile-user@gnu.org; Tue, 01 Feb 2005 12:54:05 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Cw2E0-0008E6-Om for guile-user@gnu.org; Tue, 01 Feb 2005 12:54:04 -0500 Original-Received: from [207.172.4.62] (helo=smtp03.mrf.mail.rcn.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Cw1yI-0008An-0T for guile-user@gnu.org; Tue, 01 Feb 2005 12:37:50 -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 smtp03.mrf.mail.rcn.net with esmtp (Exim 3.35 #7) id 1Cw1yB-0001Ju-00 for guile-user@gnu.org; Tue, 01 Feb 2005 12:37:43 -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 j11HbaNN019502 for ; Tue, 1 Feb 2005 12:37:42 -0500 (EST) In-Reply-To: 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 X-MailScanner-To: guile-user@m.gmane.org Xref: main.gmane.org gmane.lisp.guile.user:4200 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:4200 On Jan 21, 2005, at 13:29, Marius Vollmer wrote: > 4.3.5 Multi-Threading > --------------------- > SCM > my_list_to_vector (SCM list) > { > SCM vector = scm_make_vector (scm_length (list), SCM_UNDEFINED); > size_t len, i; > > len = SCM_SIMPLE_VECTOR_LENGTH (vector); > i = 0; > while (i < len && scm_is_pair (list)) > { > SCM_SIMPLE_VECTOR_SET (vector, i, SCM_CAR (list)); > list = SCM_CDR (list); > i++; > } > > return vector; > } > > It is safe to use `SCM_CAR' and `SCM_CDR' on the local variable LIST > once it is known that the variable contains a pair. The contents of > the pair might change spontaneously, but it will always stay a valid > pair (and a local variable will of course not spontaneously point to a > different Scheme object). But is it guaranteed that, without locking, SCM_CAR and SCM_CDR will always return the "before" or "after" values while another thread is modifying them, and not some corrupted intermediate form? Given typical data alignment and access, and hardware memory management techniques, and the small size of a SCM value, I'm not aware of a situation where it would be at all likely to happen, but I'm also not aware of any guarantee that it won't. Though, even without weird memory management issues, consider: SCM_SETCAR(x, SCM_I_MAKINUM(i >> 2)) i some external int var -> (....x)[0] = ((... i >> 2) << 2 + scm_tc2_int) -> copy i, masking off bottom two bits, into target location; then add in scm_tc2_int If SCM_CAR(x) is read at just the wrong time, the tag bits might not be correct. It may also be the case that if both the car and cdr of the pair (or indeed, any two separate locations) are modified in one thread and read in another, the memory accesses could be reordered (by the compiler, or even by the CPU these days) such that the read-back contents of the pair don't seem to match the "before" or "after" values or even the expected intermediate state where the first-listed modification has been done but the second has not. If someone's got lots more experience with multithreaded systems and wants to say I'm wrong, great. I've been thinking about this a bit lately, trying to make a pile of code thread-safe at work, but I'm mostly coming at it from a theoretical perspective. Ken _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user