views:

155

answers:

2

Here is the typical way to use a condition variable:

// The reader(s)
lock(some_mutex);
if(protected_by_mutex_var != desired_value)
    some_condition.wait(some_mutex);
unlock(some_mutex);

// The writer
lock(some_mutex);
protected_by_mutex_var = desired_value;
unlock(some_mutex);
some_condition.notify_all();

But if protected_by_mutex_var is set atomically by say, a compare-and-swap instruction, does the mutex serve any purpose (other than that pthreads and other APIs require you to pass in a mutex)? Is it protecting state used to implement the condition? If not, is it safe then to do this?:

// The writer
atomic_set(protected_by_mutex_var, desired_value);
some_condition.notify_all();

With the writer never directly interacting with the reader's mutex? Note that the 'protected_by_mutex_var' name is no longer really appropriate (it's not mutex protected anymore). If so, is it even necessary that different readers use the same mutex?

A: 

Yes, to avoid an inner race condition.

Pestilence
+7  A: 

Imagine the following scenario:

| Thread 1                                            | Thread 2                                           |
| if(protected_by_mutex_var != desired_value) -> true |                                                    |
|                                                     | atomic_set(protected_by_mutex_var, desired_value); |
|                                                     | some_condition.notify_all();                       |
| some_condition.wait(some_mutex);                    |                                                    |

This situation sees Thread 1 waiting for a notify that may never come. Because the statements acting on the condition are not part of the variable read / atomic set, this presents a race condition.

Using the mutex effectively makes these actions inseparable (assuming all accesses to the variable behave properly and lock the mutex.)

fd
Of course :p Waiting on conditions doesn't behave like poll().
Joseph Garvin