Domanda

When reading a book on concurrency, the author says a semaphore is different than a condition variable in the way signal() works. The semaphore keeps track of the number of calls to signal() while the condition variable does not. "Calling pthread_cond_signal while no one is waiting has no effect", it says. Why is this detail important (I have seen it repeated many times in different places)? What are the implications to usage? Thank you

È stato utile?

Soluzione

Conceptually, a semaphore is equivalent to a mutex, condition variable, and integer counter protected by the mutex. Under this analogy, posting a semaphore is equivalent to locking the mutex, incrementing the counter, signaling the condition variable, and unlocking the mutex. Even if there is no waiter, state is still modified.

Under this analogy, waiters for the semaphore are doing the equivalent of:

  1. Lock mutex.
  2. While count is non-positive, wait on condition variable.
  3. Decrement count.
  4. Unlock mutex.

Of course if you're talking about the specific case of POSIX, the analogy does not correspond fully to the reality, because semaphores have additional async-signal-safety properties that preclude implementing them using a mutex/condvar/count triple.

Altri suggerimenti

The implications are that you have to have a 'condition' that the condition variable is associated with. The way you have to use the condition variable is:

acquire the condition's mutex

while (!condition) {
     wait on the condition variable
}

do whatever you need to do while holding the mutex

release the mutex

Correspondingly, whenever the condition associated with the condition variable is updated, it has to be done while holding the mutex. That way, when blocking on the condition variable, the condition cannot have changed until the system is prepared to actually unblock the waiting thread.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top