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(); } > > I think there are cases with multiple threads where you can > potentially wake up the thread waiting on a condition AFTER the > condition was already reset by another. > > > 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. > > 6) Does 'shared' actually have any effect on non-global variables > > beside the syntactic regulations? > > I believe shared doesn't alter code generation at all. It only > prevents certain things and affects the type. > It shouldn't. I think in GDC it does generate different code, but that's an implementation detail that needs to be fixed.