Question

For example, every time an asynchronous operation completes which has been affecting the state of the application I do this

lock (_parent._stateObj) {

    _parent._asyncOperations.Remove(this);

    Monitor.PulseAll(_parent._stateObj);

}

I do this so that anything waiting for operations complete, like a logout routine, will be notified.

Do I/Should I be doing something more along the lines of

lock (_parent._stateObj) {

    _parent._asyncOperations.Remove(this);

    if (_parent._loggingOut) Monitor.PulseAll(_parent._stateObj);

}

Just trying to figure out if I should always be Pulsing when the internal state of the application changes. And in a large library with mostly async calls, is it true that I should more or less always use PulseAll since there can be any number of async calls taking place which have “registered” themselves in the main state of the library?

Hope this makes sense

Answer 1

Yes, it is typically acceptable, and sometimes even mandatory, to PulseAll unconditionally. The most important thing to remember is to always recheck the wait condition when calling Wait.

public void WaitingThread()
{
  lock (mylock)
  {
    while (!CanProceed())
    {
      Monitor.Wait(mylock);
    }
    // The wait condition is finally satisfied so we can proceed now.
  }
}

So if you have the blocking side of the PulseAll\Wait scheme coded correctly then it usually will not matter how the pulses are generated. Without having a better understanding of your particular situation I cannot say for sure which pulsing strategy is optimal, but I think I can at least say that pulsing unconditionally will not cause any unintended side-effects (again, assuming that the waiting side is coded correctly).