unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Neil Jerram <neil@ossau.uklinux.net>
Cc: guile-devel@gnu.org
Subject: Re: Recursive mutexes?
Date: 27 Oct 2002 07:55:56 +0000	[thread overview]
Message-ID: <m3bs5gfh83.fsf@laruns.ossau.uklinux.net> (raw)
In-Reply-To: <8765vopx30.fsf@zagadka.ping.de>

>>>>> "Marius" == Marius Vollmer <mvo@zagadka.ping.de> writes:

    Marius> Neil Jerram <neil@ossau.uklinux.net> writes:
    >> 
    >> 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.

    Marius> Yes.  But shouldn't a non-recursive mutex signal an error in this case?

Traditionally no - it just hangs.  But I can't think of a reason why
this behaviour is good, and why it wouldn't be better to signal an
error.

I'm not sure Thomas's point about traditional semantics is valid,
since mutexes are normally provided by relatively low-level interfaces
(e.g. POSIX, Win32) that don't support exceptions.

    Marius> What about having only one type of mutex but different kind of locking
    Marius> functions?  One for recursive locks and one for non-recursive error
    Marius> checking ones.  That seems mighty clean to me.

Sounds nice to me too.

    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! :-)

    Marius> Err, there's a "and" missing: "and should be avoided."

Some uses of this would be a mockery of condition variables, I agree.
But there are other possible uses, e.g. a program cleaning up before
exiting, that needs to do its thing even when other program threads
may have hung.  So, if the implementation is not too hard, I think we
should have this interface.

    Marius> Given what I have planned for our threads, we would need to implement
    Marius> our own mutexes anyway (using pthread mutexes, for example).  I would
    Marius> like to extent 'select' (with a new name) so that it can wait on IO
    Marius> and mutexes and condition variables and other stuff at the same time.

Win32 has this: `WaitForMultipleObjects'.  Can it be done in a POSIX
system without polling?

    Marius> This is something that you can build on top of the primitives, but I
    Marius> think we should offer rich tools that do a lot of useful things out of
    Marius> the box.

Totally.

        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel


  parent reply	other threads:[~2002-10-27  7:55 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 [this message]
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=m3bs5gfh83.fsf@laruns.ossau.uklinux.net \
    --to=neil@ossau.uklinux.net \
    --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).