On 9/29/15 4:38 PM, Johannes Pfau wrote:
Am Tue, 29 Sep 2015 15:10:58 -0400
schrieb Steven Schveighoffer <[email protected]>:
3) Why do I have to pass a "Mutex" to "Condition"? Why can't I just
pass an "Object"?
An object that implements the Monitor interface may not actually be a
mutex. For example, a pthread_cond_t requires a pthread_mutex_t to
operate properly. If you passed it anything that can act like a lock,
it won't work. So the Condition needs to know that it has an actual
Mutex, not just any lock-like object.
I think I advocated in the past to Sean that Condition should provide
a default ctor that just constructs a mutex, but it doesn't look like
that was done.
But you'll need access to the Mutex in user code as well.
synchronized(condition.mutex)
And often you
use multiple Conditions with one Mutex so a Condition doesn't really
own the Mutex.
It's just a different option. Often times, you have a condition
variable, and a mutex variable.
It's not super-important, you can always do:
new Condition(new Mutex);
4) Will D's Condition ever experience spurious wakeups?
What do you mean by "spurious"? If you notify a condition, anything
that is waiting on it can be woken up. Since the condition itself is
user defined, there is no way for the actual Condition to verify you
will only be woken up when it is satisfied.
In terms of whether a condition could be woken when notify *isn't*
called, I suppose it's possible (perhaps interrupted by a signal?).
But I don't know why it would matter -- per above you should already
be checking the condition while within the lock.
Spurious wakeup is a common term when talking about posix conditions
and it does indeed mean a wait() call can return without ever calling
notify():
https://en.wikipedia.org/wiki/Spurious_wakeup
http://stackoverflow.com/questions/8594591/why-does-pthread-cond-wait-have-spurious-wakeups
OK thanks.
5) Why doesn't D's Condition.wait take a predicate? I assume this is
because the answer to (4) is no.
The actual "condition" that you are waiting on is up to you to
check/define.
He probably means that you could pass an expression to wait and wait
would do the looping / check internally. That's probably a nicer API
but not implemented.
yeah, that could probably be done. One thing to note is that these
classes are from ages ago (probably close to 10 years). New API
suggestions may be allowed.
I just wanted to stress that there isn't some sort of built-in condition
predicate (like a boolean).
-Steve
