From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Rob Browning Newsgroups: gmane.lisp.guile.devel Subject: Re: Recursive mutexes? Date: Sat, 26 Oct 2002 17:16:06 -0500 Sender: guile-devel-admin@gnu.org Message-ID: <87hef86e3d.fsf@raven.i.defaultvalue.org> References: <87r8edos41.fsf@zagadka.ping.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035670611 29435 80.91.224.249 (26 Oct 2002 22:16:51 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 26 Oct 2002 22:16:51 +0000 (UTC) Cc: guile-devel@gnu.org Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 185ZEf-0007eW-00 for ; Sun, 27 Oct 2002 00:16:49 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 185ZFD-00071Z-00; Sat, 26 Oct 2002 18:17:23 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 185ZEB-0005X9-00 for guile-devel@gnu.org; Sat, 26 Oct 2002 18:16:19 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 185ZDz-0005V5-00 for guile-devel@gnu.org; Sat, 26 Oct 2002 18:16:18 -0400 Original-Received: from n66644228.ipcdsl.net ([66.64.4.228] helo=defaultvalue.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 185ZDy-0005V1-00 for guile-devel@gnu.org; Sat, 26 Oct 2002 18:16:07 -0400 Original-Received: from raven.i.defaultvalue.org (raven.i.defaultvalue.org [192.168.1.7]) by defaultvalue.org (Postfix) with ESMTP id 47AF3353E; Sat, 26 Oct 2002 17:16:06 -0500 (CDT) Original-Received: by raven.i.defaultvalue.org (Postfix, from userid 1000) id 128BF1AA; Sat, 26 Oct 2002 17:16:06 -0500 (CDT) Original-To: Marius Vollmer In-Reply-To: <87r8edos41.fsf@zagadka.ping.de> (Marius Vollmer's message of "26 Oct 2002 22:35:58 +0200") Original-Lines: 62 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.2 (i386-pc-linux-gnu) Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:1607 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1607 Marius Vollmer writes: > Our current coop mutexes are not 'recursive'. This means that a > thread blocks when it tries to lock a mutex that it already has > locked. > > I think we should make our mutexes be recursive by default. Expecting > to block when locking a mutex that is already lcoked by one self is > not very useful, since no one can unlock that mutex (excepts asyncs). Though people coming from POSIX threads (at least under glibc) will be used to having to explicitly ask for recursive mutexes, and at least at the C level, there's apparently an efficiency issue involved. Would it be hard to provide both and let the user select at creation time? > The only good argument against recursive mutexes that I can think of > is a tiny performance gain since you don't need to do some checking. I guess to some extent it would depend on how tiny the gain would be :> > SRFI-18 specifies non-recursive mutexes and allows non-owning threads > to unlock a mutex. Such uses of a mutex are, in my view, a mockery of > condition variables should be avoided. Well you certainly could use a condition variable instead of a mutex here, but I would suspect that in cases where you just want to wake someone else up, a mutex others can unlock would be lighter weight. With a condition variable you have to have both a mutex and the condition variable. It sounds like the SRFI-18 mutexes are just POSIX Semaphores with one token, and POSIX Semaphores are more flexible, and seem only trivially harder to implement -- likely not much more than adding an integer counter and a few trivial numeric comparisons. If so, I'd rather have a POSIX Semaphore and provide a trivial wrapper that satisfies SRFI-18. In POSIX mutexes are pretty low-level -- they're more or less just an atomic lock -- that makes sense since they're the simplest portable sync type. Semaphores and Condition Variables are for anything more than the most basic operations, and even there (as you and I talked about), there are no FIFO fairness guarantees, so you're often faced with building your own sync operations on top of them. One thing that the POSIX model has going for it is exposure -- I suspect a lot of people are familiar with how the API works, so my default inclination would be to follow that API whenever there's not a good reason not to. We may also want to add some enhancements like FIFO guarantees that don't contradict the standard, but that's a separate question. IMO thread programming is hard. Writing correct algorithms using threads can be hard, and if someone already has something they've written using the POSIX semantics that works, it will be a lot easier to migrate to another language if the semantics are similar. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel