From: Marius Vollmer <mvo@zagadka.ping.de>
Cc: guile-devel@gnu.org
Subject: Re: Recursive mutexes?
Date: 27 Oct 2002 02:35:54 +0200 [thread overview]
Message-ID: <871y6cpvkl.fsf@zagadka.ping.de> (raw)
In-Reply-To: <87hef86e3d.fsf@raven.i.defaultvalue.org>
Rob Browning <rlb@defaultvalue.org> writes:
> > 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,
I am confused by the libc docs: what is a "timed" mutex? Is it
recursive or not? I just checked a little test program and the
default pthread mutexes seem to be recursive, on GNU/Linux. "Fast"
mutixes are not resursive but you have to ask for them.
> Would it be hard to provide both and let the user select at creation
> time?
No. But what about having two sets of locking/unlocking functions:
one that behaves recursivly, and one that doesn't?
> > 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.
And for a good reason, no?
--
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
next prev parent reply other threads:[~2002-10-27 0:35 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
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 [this message]
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=871y6cpvkl.fsf@zagadka.ping.de \
--to=mvo@zagadka.ping.de \
--cc=guile-devel@gnu.org \
/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).