Re: Recursive mutexes?

[Marius Vollmer <mvo@zagadka.ping.de>]

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?

> IIRC, it's easy to implement a recursive mutex if you already have a
> non-recursive one, but the reverse is not so easy.

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.

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.

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

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

>     Marius> If non-recursive mutexes turn out to be important, we
>     Marius> can provide them as well, as an option.
> 
> I'm pretty sure they are important (enough), so I suggest that we
> provide both.  What would be quite nice (and I think is possible)
> would be to implement non-recursive mutexes in a
> thread-implementation-specific way, and then recursive mutexes in a
> generic way based on whatever non-recursive mutex is currently
> configured.

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

That is, you would be able to wait for two condition variables, say,
and wake up when one of them is signalled.

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

-- 
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