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 13:36:22 +0100 Sender: guile-devel-admin@gnu.org Message-ID: <87elacnjnd.fsf@zagadka.ping.de> References: <87r8edos41.fsf@zagadka.ping.de> <8765vopx30.fsf@zagadka.ping.de> <87smysn0d0.fsf@becket.becket.net> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035722181 21977 80.91.224.249 (27 Oct 2002 12:36:21 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 27 Oct 2002 12:36:21 +0000 (UTC) Cc: Neil Jerram , 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 185meR-0005iJ-00 for ; Sun, 27 Oct 2002 13:36:19 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 185mfE-0001kP-00; Sun, 27 Oct 2002 07:37:08 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 185meY-0001an-00 for guile-devel@gnu.org; Sun, 27 Oct 2002 07:36:26 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 185meV-0001aI-00 for guile-devel@gnu.org; Sun, 27 Oct 2002 07:36:25 -0500 Original-Received: from mail.dokom.net ([195.253.8.218]) by monty-python.gnu.org with esmtp (Exim 4.10) id 185meV-0001a3-00 for guile-devel@gnu.org; Sun, 27 Oct 2002 07:36:23 -0500 Original-Received: from dialin.speedway43.dip227.dokom.de ([195.138.43.227] helo=zagadka.ping.de ident=qmailr) by mail.dokom.net with smtp (Exim 3.32 #2) id 185mf9-0007oq-00 for guile-devel@gnu.org; Sun, 27 Oct 2002 13:37:03 +0100 Original-Received: (qmail 6576 invoked by uid 1000); 27 Oct 2002 12:36:22 -0000 Original-To: tb@becket.net (Thomas Bushnell, BSG) In-Reply-To: <87smysn0d0.fsf@becket.becket.net> Original-Lines: 67 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:1624 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1624 tb@becket.net (Thomas Bushnell, BSG) writes: [ locking a non-recursive mutex when it is already locked by the same thread.] > > Yes. But shouldn't a non-recursive mutex signal an error in this case? > > No. A non-recursive mutex should block in a case like this. Why? Because it is cheaper, or because it is the Right Thing? > It's not an error to try and lock a mutex which is already locked, > even if it's already locked by your own thread. What use does this have? Are there well-known patterns were you rely on this? > Please, there are already standard semantics for these objects, in > use across a jillion languages. Are there? Do they really all agree on whether mutexes are recursive or not, and whether you are allowed to unlock a mutex from a non-owning thread, and on what should happen when you lock a non-recursive mutex that you already own? I don't have that impression, from my admittedly little experience. Can you point me to a description of these standard semantics? You sound like they are obvious, but they are not to me, yet. > Changing them is a little like deciding that you are going to > implement integer addition as NIM addition, normal conventions be > damned. It's more like deciding to offer bignums in addition, because they are nicer than modulo 2^x arithmetic. Most people don't want module 2^x arithmetic when they use "int" in C, they just are careful to stay within the region where C integer addition models real integer addition. What was the reason again to go to 64 bit? That the UNIX clock will not roll over? ;-) Right now, I suspect that the reason d'etre for non-recursive mutexes is that they are faster. Nothing more. I would like to hear other reasons since the cost of recursive mutexes is not too high, in my view. > > 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. > > Why? Recursive mutexes are much more heavyweight in general, and are > usually totally unnecessary. "Much more" is a subjective measure. As I see it, "much more" amounts to two additional fields in the data structure and one comparison during lock and unlock each. This is not much more for the context that our mutexes operate in. > > 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. > > The only implementation of such a thing which I've thought of ends up > imposing the extra cost of a recursive mutex on all users. Yes. I am not trying to lower the cost here but to give non-recursive mutexes to people who want them. -- 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