Threading Questions

[Steven Schveighoffer via Digitalmars-d-learn]

On 9/29/15 4:38 PM, Johannes Pfau wrote:
> Am Tue, 29 Sep 2015 15:10:58 -0400
> schrieb Steven Schveighoffer <schveiguy at 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.

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