From: Rob Browning <rlb@defaultvalue.org>
Cc: guile-devel@gnu.org
Subject: Re: Recursive mutexes?
Date: Sat, 26 Oct 2002 23:36:21 -0500 [thread overview]
Message-ID: <871y6c5whm.fsf@raven.i.defaultvalue.org> (raw)
In-Reply-To: <871y6cpvkl.fsf@zagadka.ping.de> (Marius Vollmer's message of "27 Oct 2002 02:35:54 +0200")
Marius Vollmer <mvo@zagadka.ping.de> writes:
> I am confused by the libc docs: what is a "timed" mutex? Is it
> recursive or not?
Good question -- I had wondered if the two things were orthogonal,
i.e. you could select create (mutex, RECURSIVE | TIMED), but from
looking at the docs it's not clear to me, but they don't look
orthogonal. The timed mutex was actually news to me -- I hadn't
realized they'd added those.
(I think perhaps I've been thinking more of the older threads
implementation which wasn't quite the same as posix.)
> 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.
Hmm. Now I'm confused. I'd read the libc docs and it had looked to
me like fast mutexes were the default (they used to be), but now I see
that the libc docs say that fast mutexes are the default in the
*LinuxThreads* implementation. The libc docs unfortunately don't seem
to say much about when you would be using the LinuxThreads
implementation as opposed to a posix one. (have to go poke around and
see what the deal is these days)
> No. But what about having two sets of locking/unlocking functions:
> one that behaves recursivly, and one that doesn't?
You could do that. I think perhaps the reason posix doesn't is
because the non-recursive ones may be more efficient on a given
platform, and some people are be watching every cycle. If that's the
only issue, then we may not care.
>> 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?
Not sure I follow.
--
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
next prev parent reply other threads:[~2002-10-27 4:36 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
2002-10-27 4:36 ` Rob Browning [this message]
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=871y6c5whm.fsf@raven.i.defaultvalue.org \
--to=rlb@defaultvalue.org \
--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).