From: tb@becket.net (Thomas Bushnell, BSG)
Cc: Neil Jerram <neil@ossau.uklinux.net>, guile-devel@gnu.org
Subject: Re: Recursive mutexes?
Date: 26 Oct 2002 18:20:43 -0700 [thread overview]
Message-ID: <87smysn0d0.fsf@becket.becket.net> (raw)
In-Reply-To: <8765vopx30.fsf@zagadka.ping.de>
Marius Vollmer <mvo@zagadka.ping.de> writes:
> Neil Jerram <neil@ossau.uklinux.net> writes:
>
> > >>>>> "Marius" == Marius Vollmer <mvo@zagadka.ping.de> 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?
No. A non-recursive mutex should block in a case like this.
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.
Please, there are already standard semantics for these objects, in use
across a jillion languages. Changing them is a little like deciding
that you are going to implement integer addition as NIM addition,
normal conventions be damned.
> 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.
> 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.
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
next prev parent reply other threads:[~2002-10-27 1:20 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-26 20:35 Recursive mutexes? Marius Vollmer
2002-10-26 21:39 ` Neil Jerram
2002-10-27 0:03 ` Marius Vollmer
2002-10-27 1:20 ` Thomas Bushnell, BSG [this message]
2002-10-27 12:36 ` Marius Vollmer
2002-10-27 7:55 ` Neil Jerram
2002-10-27 18:33 ` Rob Browning
2002-10-26 22:16 ` Rob Browning
2002-10-26 22:29 ` Rob Browning
2002-10-26 22:42 ` Tom Lord
2002-10-26 23:26 ` Thomas Bushnell, BSG
2002-10-26 23:35 ` Tom Lord
2002-10-26 23:50 ` Tom Lord
2002-10-27 1:18 ` Thomas Bushnell, BSG
2002-10-26 22:47 ` Tom Lord
2002-10-27 8:33 ` Neil Jerram
2002-10-27 17:21 ` Tom Lord
2002-10-27 0:35 ` Marius Vollmer
2002-10-27 4:36 ` Rob Browning
2002-10-27 11:32 ` Marius Vollmer
2002-10-27 18:44 ` Rob Browning
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87smysn0d0.fsf@becket.becket.net \
--to=tb@becket.net \
--cc=guile-devel@gnu.org \
--cc=neil@ossau.uklinux.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).