On Tuesday, September 29, 2015 22:38:42 Johannes Pfau via Digitalmars-d-learn wrote: > Am Tue, 29 Sep 2015 15:10:58 -0400 > schrieb Steven Schveighoffer <schvei...@yahoo.com>: > > > > > > 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. And often you > use multiple Conditions with one Mutex so a Condition doesn't really > own the 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 > > And yes, this does happen for core.sync.condition as well. As a result > you'll always have to check in a loop: > > synchronized(mutex) > { > while(some_flag_or_expression) > { > cond.wait(); > } > } > > ----------------- > synchronized(mutex) > { > some_flag_or_expression = true; > cond.notify(); > }
What I took from the answers to that SO question was that in general, it really doesn't matter whether a condition variable has spurious wakeups. You're going to have to check that the associated bool is true when you wake up anyway. Maybe without spurious wakeups, it wouldn't be required if only one thread was waiting for the signal, but you'd almost certainly still need an associated bool in case it becomes true prior to waiting. In addition, if you want to avoid locking up your program, it's ferquently the case that you want a timed wait so that you can check whether the program is trying to exit (or at least that the thread in question is being terminated), and you'd need a separate bool in that case as well so that you can check whether the condition has actually been signaled. So, ultimately, while spurious wakeups do seem wrong from a correctness perspective, when you look at what a condition variable needs to do, it usually doesn't matter that spurious wakeups exist, and a correctly used condition variable will just handle spurious wakeups as a side effect of how it's used. - Jonathan M Davis
