From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.devel Subject: Re: srfi-18 requirements Date: Fri, 25 Jan 2008 01:07:09 +0000 Message-ID: <877ihy3e82.fsf@ossau.uklinux.net> References: <2bc5f8210710101854m1254160ei451026182b87e767@mail.gmail.com> <87fxxh8isb.fsf@ossau.uklinux.net> <2bc5f8210801032101x33db423ak7bf7950c378ae27e@mail.gmail.com> <87abnldsg5.fsf@ossau.uklinux.net> <2bc5f8210801061341o5a8b060fm3e80d6b9cb8eb4d6@mail.gmail.com> <87prwb3oc4.fsf@ossau.uklinux.net> <2bc5f8210801101839w2b6ab7f8h3d99b6db35620a6@mail.gmail.com> <874pddcjdf.fsf@ossau.uklinux.net> <2bc5f8210801191210h72903a37q1c8f60e3638bfdba@mail.gmail.com> <87ejc8kvnk.fsf@ossau.uklinux.net> <2bc5f8210801231523k62e9f6ddq17eb87c69df5ae16@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1201223250 4128 80.91.229.12 (25 Jan 2008 01:07:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 25 Jan 2008 01:07:30 +0000 (UTC) Cc: =?iso-8859-1?Q?Ludovic_Court=E8s?= , guile-devel@gnu.org To: "Julian Graham" Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Jan 25 02:07:49 2008 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JID2q-0004In-Ej for guile-devel@m.gmane.org; Fri, 25 Jan 2008 02:07:48 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JID2Q-00067k-4o for guile-devel@m.gmane.org; Thu, 24 Jan 2008 20:07:22 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JID2M-00065O-PL for guile-devel@gnu.org; Thu, 24 Jan 2008 20:07:18 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JID2L-000650-Jv for guile-devel@gnu.org; Thu, 24 Jan 2008 20:07:18 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JID2L-00064x-GQ for guile-devel@gnu.org; Thu, 24 Jan 2008 20:07:17 -0500 Original-Received: from mail3.uklinux.net ([80.84.72.33]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JID2G-0003QI-T5; Thu, 24 Jan 2008 20:07:13 -0500 Original-Received: from arudy (host86-145-183-175.range86-145.btcentralplus.com [86.145.183.175]) by mail3.uklinux.net (Postfix) with ESMTP id F22C41F7287; Fri, 25 Jan 2008 01:07:10 +0000 (GMT) Original-Received: from laruns (unknown [192.168.0.10]) by arudy (Postfix) with ESMTP id EB8443800A; Fri, 25 Jan 2008 01:07:09 +0000 (GMT) In-Reply-To: <2bc5f8210801231523k62e9f6ddq17eb87c69df5ae16@mail.gmail.com> (Julian Graham's message of "Wed, 23 Jan 2008 18:23:22 -0500") User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 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:6975 Archived-At: "Julian Graham" writes: > Hi Neil, Hello again! I've added some comments below, but I think that for the last few emails we've rather lost sight of the ball - mostly my fault, for pursuing details that didn't need pursuing. So actually my comments below are not really important. Looking back, and clawing our way back towards SRFI-18 (remember that :-), I suggest that - I'll stop raising unproven issues in the threads code! - we apply the generic / bug fix patch that you already posted, except without the extra thread_admin_mutex locking (which I think we concluded we can't justify) - that will be to HEAD - I'll have a go at devising a test for the critical section in make_jmpbuf bug; if I succeed, I'll run the test on 1.8.x too, and port the fix over - you continue on the C enhancements and Scheme code for SRFI-18, as already discussed and agreed - once all of your code and tests are in (HEAD), we can see if there are any _actual_ generic thread code issues that we need to address, and address them. What do you think? > Ignoring... (but is that what all_threads is for? My understanding > was that it was for ALL threads created by / initialized to use Guile > -- i.e., all threads that needed to be GC'd.) (I'm not sure, but I think that (i) a thread that has left guile mode ain't gonna call SCM_TICK, and (ii) the fact that all threads need to be GC'd is handled by the thread saving its stack top and flushing its registers in suspend(). But in any case, we should leave this until someone writes a cunning test case to expose it.) > I don't think this is possible -- the GC thread could never have > gotten to that point unless it had locked the non-GC thread's > heap_mutex. By the time it sets wake_up_flag to 1, it must also be > holding the wake_up_mutex, which means that the non-GC thread had > already relinquished it via the cond_wait. Yes, agreed now. (Note that this does rely on the overlapping, and so this is the "hard reason".) > I think that they do (need to overlap). And I'm having a hard time > seeing the potential for deadlock here (maybe I'm just sluggish from > the heat in my cubicle). I think the order of locking is critical to > preventing deadlock, in fact, via a race on wake_up_flag. In the > situation you describe, the non-GC thread will only be able to seize > wake_up_mutex once the wake_up_flag has been set and the GC thread has > permanently relinquished wake_up_mutex for that round of collection, > so there's no deadlock. Am I missing something? No, you're very likely right. I think from here on the onus should be on me (or anyone else) to come up with an actual test, instead of trying to argue theoretically. (And for the same reason, I don't think we should apply your new code to CVS yet, because I don't think we've yet demonstrated an actual problem with the existing code - is that right?) Regards, Neil