Re: condition variables and mutexes

[Jim Blandy <jimb@red-bean.com>]

> Well, in Scheme programming, it would be.  However, in C programming,
> there is a good reason why the condition variable is implemented
> independent with mutex.  Here is my understanding.

[Please excuse the last empty message.]

It sounds like the performance rationale for keeping them separate doesn't
apply to interpreted systems.  However, there's a readability
question, as well.  If the mutex is an argument to condition-wait, then
it's clear from the text that you are temporarily releasing the same
lock you acquired earlier, and will release later.  If the mutex is
a part of the condition variable, then you must discover where the
condition variable was created (possibly far away, and long ago) to be
sure you're temporarily releasing the same lock you acquired.

>From a readability point of view, one would want an object, maybe
called a monitor, that has a mutex and a condition variable in it, and
can be locked and waited on.  Thus, you'd write code like this:

	monitor_lock (mon);
        ...
        while (! some condition)
           monitor_wait (mon);
        ...
        monitor_unlock (mon);

As I said, threading is not my forte; perhaps this is already done,
and called something else?  Or perhaps it is generally avoided for
some reason.  But it is certainly easy to look at such code and verify
that:

1) We're temporarily releasing the same mutex we acquired earlier, and
2) We're using the appropriate mutex for that condition variable.

If what Maciej said earlier, that there should be a 1-1 correspondence
between mutexes and condition variables, then it should not be too
restrictive.

I'm not suggesting that Guile replace mutexes and condition variables
in favor of monitors --- rather, that it would offer them in addition
to monitors.