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: Tue, 08 Jan 2008 23:11:07 +0000 Message-ID: <87prwb3oc4.fsf@ossau.uklinux.net> References: <2bc5f8210710101854m1254160ei451026182b87e767@mail.gmail.com> <2bc5f8210710151547l5e245ed1ucaf07e9006e95387@mail.gmail.com> <2bc5f8210710290737j32fe7b1s86aaa7e084bb69b6@mail.gmail.com> <87ve7mmdpl.fsf@chbouib.org> <2bc5f8210712172030h101f71e2w95265d138ffdb2a8@mail.gmail.com> <87odc88muv.fsf@ossau.uklinux.net> <2bc5f8210712301238w583feb99w96bb77ed389eac50@mail.gmail.com> <87fxxh8isb.fsf@ossau.uklinux.net> <2bc5f8210801032101x33db423ak7bf7950c378ae27e@mail.gmail.com> <87abnldsg5.fsf@ossau.uklinux.net> <2bc5f8210801061341o5a8b060fm3e80d6b9cb8eb4d6@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 1199833887 13325 80.91.229.12 (8 Jan 2008 23:11:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 8 Jan 2008 23:11:27 +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 Wed Jan 09 00:11: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 1JCNbl-0001yj-Eu for guile-devel@m.gmane.org; Wed, 09 Jan 2008 00:11:45 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JCNbO-0001hc-37 for guile-devel@m.gmane.org; Tue, 08 Jan 2008 18:11:22 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JCNbJ-0001f5-Sj for guile-devel@gnu.org; Tue, 08 Jan 2008 18:11:18 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JCNbI-0001dF-Bb for guile-devel@gnu.org; Tue, 08 Jan 2008 18:11:16 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JCNbI-0001d4-5q for guile-devel@gnu.org; Tue, 08 Jan 2008 18:11:16 -0500 Original-Received: from mail3.uklinux.net ([80.84.72.33]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JCNbD-00010a-Ni; Tue, 08 Jan 2008 18:11:12 -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 4488C1F78E3; Tue, 8 Jan 2008 23:11:09 +0000 (GMT) Original-Received: from laruns (unknown [192.168.0.10]) by arudy (Postfix) with ESMTP id 436CD3800A; Tue, 8 Jan 2008 23:11:08 +0000 (GMT) In-Reply-To: <2bc5f8210801061341o5a8b060fm3e80d6b9cb8eb4d6@mail.gmail.com> (Julian Graham's message of "Sun, 6 Jan 2008 16:41:34 -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:6954 Archived-At: "Julian Graham" writes: > Hi Neil, > >> > Of course. >> >> Good, thanks. > > Find attached a patch against HEAD that includes only the bug fix > stuff (2 deadlocks and use of thread-specific admin mutex) from the > original patch, modified to change make_jmpbuf instead of the signal > delivery code. Thanks. Just a couple further points... > static void > scm_enter_guile (scm_t_guile_ticket ticket) > { > scm_i_thread *t = (scm_i_thread *)ticket; > if (t) > { > + /* The admin mutex must be locked here to prevent the thread from > + entering guile-mode after scm_thread_go_to_sleep has been set to 1 in > + scm_i_thread_go_to_sleep. */ > + > + scm_i_pthread_mutex_lock (&thread_admin_mutex); > scm_i_pthread_mutex_lock (&t->heap_mutex); > resume (t); > + scm_i_pthread_mutex_unlock (&thread_admin_mutex); > } > } 1. Embarassingly - given that I already said "Nice fix" to this - I'm afraid I can't now see exactly why this is needed. I understand that if the line to lock thread_admin_mutex is absent, it is possible for this thread (A, say) to lock its heap_mutex, and call resume(), and return from scm_enter_guile(), even though scm_i_thread_go_to_sleep is already 1. I'm not sure why this is a problem, though. It seems to me that what will then ensue is that - scm_i_thread_put_to_sleep() will block when it tries to lock thread A's heap_mutex - after a short while, thread A will call SCM_TICK, which will call SCM_THREAD_SWITCHING_CODE, which will notice that scm_i_thread_go_to_sleep is 1 and so call scm_i_thread_sleep_for_gc() - scm_i_thread_sleep_for_gc() will do the cond_wait, releasing the heap_mutex, and so allowing the GC thread to lock it. So the worst that happens is that thread A manages to do a little more guile mode execution before it goes to sleep. Is that right? I think you suggested in one of your previous emails that it might be possible for thread A to enter and leave guile mode multiple times, but I don't see how that is possible. 2. Should admin_mutex be locked in scm_c_thread_exited_p()? I think it should. (This was equally wrong when using thread_admin_mutex, of course; your patch doesn't make anything worse, but it's worth fixing this in passing if you agree.) Regards, Neil