This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
> 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.