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: Thu, 15 May 2008 00:11:36 +0100 Message-ID: <87ve1gscpj.fsf@ossau.uklinux.net> References: <2bc5f8210710101854m1254160ei451026182b87e767@mail.gmail.com> <873ariaq82.fsf@ossau.uklinux.net> <2bc5f8210803011156i3bfb976bsda2a7902654ba3a6@mail.gmail.com> <87bq5pb2ea.fsf@ossau.uklinux.net> <2bc5f8210803102102p31da06b5jfa7807bb727907a7@mail.gmail.com> <87myonlqys.fsf@ossau.uklinux.net> <2bc5f8210803260855m2f1a8295v5b9becfa615c7a8d@mail.gmail.com> <877iffssdn.fsf@ossau.uklinux.net> <2bc5f8210804031207s25be680aj99b50eaa1d66b6d7@mail.gmail.com> <87tziaogxp.fsf@ossau.uklinux.net> <2bc5f8210804131743p10e3a24bu15a4fb1985f72d1b@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 1210806734 23773 80.91.229.12 (14 May 2008 23:12:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 14 May 2008 23:12:14 +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 Thu May 15 01:12:50 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 1JwQ9D-0006bi-97 for guile-devel@m.gmane.org; Thu, 15 May 2008 01:12:35 +0200 Original-Received: from localhost ([127.0.0.1]:59215 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JwQ8T-00075t-Ug for guile-devel@m.gmane.org; Wed, 14 May 2008 19:11:49 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JwQ8R-00075Y-N4 for guile-devel@gnu.org; Wed, 14 May 2008 19:11:47 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JwQ8Q-00074T-UG for guile-devel@gnu.org; Wed, 14 May 2008 19:11:47 -0400 Original-Received: from [199.232.76.173] (port=53363 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JwQ8Q-00074O-QA for guile-devel@gnu.org; Wed, 14 May 2008 19:11:46 -0400 Original-Received: from mail3.uklinux.net ([80.84.72.33]:56138) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JwQ8J-0001fK-F5; Wed, 14 May 2008 19:11:40 -0400 Original-Received: from arudy (host86-149-179-1.range86-149.btcentralplus.com [86.149.179.1]) by mail3.uklinux.net (Postfix) with ESMTP id D285F1F66BE; Thu, 15 May 2008 00:11:37 +0100 (BST) Original-Received: from laruns (laruns [192.168.0.10]) by arudy (Postfix) with ESMTP id 388903800D; Thu, 15 May 2008 00:11:37 +0100 (BST) In-Reply-To: <2bc5f8210804131743p10e3a24bu15a4fb1985f72d1b@mail.gmail.com> (Julian Graham's message of "Sun, 13 Apr 2008 20:43:26 -0400") 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:7248 Archived-At: "Julian Graham" writes: > Find attached a patch (in two parts [...] Thanks; I've reviewed and applied those to my tree, and rebuilding now; will push shortly unless I see any build errors. > * Re-added support for locking mutexes with an owner other than the > current thread > * Enabled the previously ifdef'd out functions scm_mutex_owner and > scm_mutex_level > * Added a new function, scm_mutex_locked_p, useful for distinguishing > between unlocked and unowned mutex states. > * Updated the threads.test file to reflect the changes above > * Updated the documentation in api-scheduling.texi to reflect the changes above > * Updated the ChangeLog to reflect the changes above All great. > Also attached are updated versions of the Scheme SRFI-18 > implementation as well as the SRFI-18-specific test code. I haven't covered these yet. Will try to soon, but could you resubmit anyway as a GIT commit patch, so that you end up being properly credited for the commit? > A couple of notes: For purposes of elegance, I've changed semantics of > fat_mutex.level -- where previously all non-recursive mutexes had a > level of -1, recursiveness is now denoted by an integer field on > fat_mutex. Any mutex (recursive or not) is in a locked state iff its > level is greater than 0. Cool; I think this is nicer than the previous -1 representation. > Second, during the testing I did for this round of changes, I noticed > a few more deadlocks that I believe are related to the existing core > threading model (as opposed to the changes included in this patch). > These seem to crop up when I run overnight tests on modified core > code, probably because different timings and thread interactions are > introduced. I think I've got fixes for some of them, and I'll > follow-up in a separate mailing list thread. OK. I'll look out for those. Even though I've already committed, I had one query... > @@ -1211,79 +1212,77 @@ SCM_DEFINE (scm_make_recursive_mutex, "make-recursive-mutex", 0, 0, 0, > SCM_SYMBOL (scm_abandoned_mutex_error_key, "abandoned-mutex-error"); > > static SCM > -fat_mutex_lock (SCM mutex, scm_t_timespec *timeout, int *ret) > +fat_mutex_lock (SCM mutex, scm_t_timespec *timeout, SCM owner, int *ret) > { > fat_mutex *m = SCM_MUTEX_DATA (mutex); > > - SCM thread = scm_current_thread (); > - scm_i_thread *t = SCM_I_THREAD_DATA (thread); > - > + SCM new_owner = SCM_UNBNDP (owner) ? scm_current_thread() : owner; > SCM err = SCM_BOOL_F; > > struct timeval current_time; > > scm_i_scm_pthread_mutex_lock (&m->lock); > - if (scm_is_false (m->owner)) > - { > - m->owner = thread; > - scm_i_pthread_mutex_lock (&t->admin_mutex); > - t->mutexes = scm_cons (mutex, t->mutexes); > - scm_i_pthread_mutex_unlock (&t->admin_mutex); > - *ret = 1; > - } > - else if (scm_is_eq (m->owner, thread)) > + > + while (1) > { > - if (m->level >= 0) > + if (m->level == 0) > { > + m->owner = new_owner; > m->level++; > - *ret = 1; > - } > - else > - err = scm_cons (scm_misc_error_key, > - scm_from_locale_string ("mutex already locked by " > - "current thread")); > - } > - else > - { > - int first_iteration = 1; > - while (1) > - { > - if (scm_is_eq (m->owner, thread) || scm_c_thread_exited_p (m->owner)) > + > + if (SCM_I_IS_THREAD (new_owner)) > { > + scm_i_thread *t = SCM_I_THREAD_DATA (new_owner); > scm_i_pthread_mutex_lock (&t->admin_mutex); > t->mutexes = scm_cons (mutex, t->mutexes); > scm_i_pthread_mutex_unlock (&t->admin_mutex); > - *ret = 1; > - if (scm_c_thread_exited_p (m->owner)) > - { > - m->owner = thread; > - err = scm_cons (scm_abandoned_mutex_error_key, > - scm_from_locale_string ("lock obtained on " > - "abandoned mutex")); > - } > - break; > } > - else if (!first_iteration) > + *ret = 1; > + break; > + } > + else if (SCM_I_IS_THREAD (m->owner) && scm_c_thread_exited_p (m->owner)) > + { > + m->owner = new_owner; Should m->level be set to 1 here? Regards, and thanks once again for your work on this area! Neil