From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.lisp.guile.devel Subject: Re: Recursive mutexes? Date: 27 Oct 2002 02:03:15 +0200 Sender: guile-devel-admin@gnu.org Message-ID: <8765vopx30.fsf@zagadka.ping.de> 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 1035677151 9345 80.91.224.249 (27 Oct 2002 00:05:51 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 27 Oct 2002 00:05: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 185aw9-0002Qa-00 for ; Sun, 27 Oct 2002 02:05: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 185auV-0000wm-00; Sat, 26 Oct 2002 20:04:07 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 185atk-00088A-00 for guile-devel@gnu.org; Sat, 26 Oct 2002 20:03:20 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 185ath-00080t-00 for guile-devel@gnu.org; Sat, 26 Oct 2002 20:03:19 -0400 Original-Received: from mail.dokom.net ([195.253.8.218]) by monty-python.gnu.org with esmtp (Exim 4.10) id 185atg-00080P-00 for guile-devel@gnu.org; Sat, 26 Oct 2002 20:03:16 -0400 Original-Received: from dialin.speedway42.dip231.dokom.de ([195.138.42.231] helo=zagadka.ping.de ident=qmailr) by mail.dokom.net with smtp (Exim 3.32 #2) id 185auK-0003Bb-00 for guile-devel@gnu.org; Sun, 27 Oct 2002 02:03:56 +0200 Original-Received: (qmail 14675 invoked by uid 1000); 27 Oct 2002 00:03:15 -0000 Original-To: Neil Jerram In-Reply-To: Original-Lines: 56 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 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:1615 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1615 Neil Jerram writes: > >>>>> "Marius" == Marius Vollmer writes: > > Marius> I think we should make our mutexes be recursive by > Marius> default. Expecting to block when locking a mutex that > Marius> is already lcoked by one self is not very useful, since > Marius> no one can unlock that mutex (excepts asyncs). > > True, but a situation like this (the same thread trying to relock the > same mutex) can alert you to a programming error. A dramatic problem > (the program hanging) is often more useful than the error being hidden. Yes. But shouldn't a non-recursive mutex signal an error in this case? > IIRC, it's easy to implement a recursive mutex if you already have a > non-recursive one, but the reverse is not so easy. Yes, true. But what should be the default type? We should offer recursive mutexes in any case, and I think they should be the default. What about having only one type of mutex but different kind of locking functions? One for recursive locks and one for non-recursive error checking ones. That seems mighty clean to me. > Marius> Such uses of a mutex are, in my view, a mockery of > Marius> condition variables should be avoided. > > I think you'll have to rephrase that! :-) Err, there's a "and" missing: "and should be avoided." > Marius> If non-recursive mutexes turn out to be important, we > Marius> can provide them as well, as an option. > > I'm pretty sure they are important (enough), so I suggest that we > provide both. What would be quite nice (and I think is possible) > would be to implement non-recursive mutexes in a > thread-implementation-specific way, and then recursive mutexes in a > generic way based on whatever non-recursive mutex is currently > configured. Given what I have planned for our threads, we would need to implement our own mutexes anyway (using pthread mutexes, for example). I would like to extent 'select' (with a new name) so that it can wait on IO and mutexes and condition variables and other stuff at the same time. That is, you would be able to wait for two condition variables, say, and wake up when one of them is signalled. This is something that you can build on top of the primitives, but I think we should offer rich tools that do a lot of useful things out of the box. -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel