Threading Questions

[Steven Schveighoffer via Digitalmars-d-learn]

On 9/25/15 11:19 AM, bitwise wrote:
> Hey, I've got a few questions if anybody's got a minute.
>
> I'm trying to wrap my head around the threading situation in D. So far,
> things seem to be working as expected, but I want to verify my solutions.
>
> 1) Are the following two snippets exactly equivalent(not just in
> observable behaviour)?
> a)
>
> Mutex mut;
> mut.lock();
> scope(exit) mut.unlock();
>
> b)
> Mutex mut;
> synchronized(mut) { }
>
> Will 'synchronized' call 'lock' on the Mutex, or do something
> else(possibly related to the interface Object.Monitor)?

Yes. A mutex object has it's internal lock as its monitor.

> 2) Phobos has 'Condition' which takes a Mutex in the constructor. The
> documentation doesn't exactly specify this, but should I assume it works
> the same as std::condition_variable in C++?

I am not sure about std::condition_variable. core.sync.condition works 
like a standard condition 
(https://en.wikipedia.org/wiki/Monitor_%28synchronization%29)

> For example, is this correct?
>
> Mutex mut;
> Condition cond = new Condition(mut);
>
> // mut must be locked before calling Condition.wait
> synchronized(mut)  // depends on answer to (1)
> {
>      // wait() unlocks the mutex and enters wait state
>      // wait() must re-acquire the mutex before returning when cond is
> signalled
>      cond.wait();
> }

Yes, I believe it is.

> 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.

>
> 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.

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.

> 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.

> I know that all global variables are TLS unless explicitly marked as
> 'shared', but someone once told me something about 'shared' affecting
> member variables in that accessing them from a separate thread would
> return T.init instead of the actual value... or something like that.
> This seems to be wrong(thankfully).

No, this isn't true.

> For example, I have created this simple Worker class which seems to work
> fine without a 'shared' keyword in sight(thankfully). I'm wondering
> though, if there would be any unexpected consequences of doing things
> this way.
>
> http://dpaste.com/2ZG2QZV

Some errors:

1. When calling notifyAll, you should ALWAYS have the mutex locked.
2. Since the mutex is protecting _run, it should only be 
checked/modified with the lock held.
3. After you have been woken up, you should check that the condition is 
satisfied.
4. Technically, you shouldn't access member variables that are GC 
allocated from a dtor. I know it's a struct, but structs can be GC 
allocated as well.

I would replace your if(tasks.empty) with while(tasks.empty && _run) to 
fix issue 3.

-Steve