// Win32 and OS/2 don't have explicit support for the POSIX condition
// variables and their events/event semaphores have quite different semantics,
// so we reimplement the conditions from scratch using the mutexes and
// semaphores
// Win32 and OS/2 don't have explicit support for the POSIX condition
// variables and their events/event semaphores have quite different semantics,
// so we reimplement the conditions from scratch using the mutexes and
// semaphores
- // after a thread increments nwaiters, and unlocks the mutex and before the
- // semaphore.Wait() is called, if another thread can cause a signal to be
- // generated
+ // after a thread increments m_numWaiters, and unlocks the mutex and before
+ // the semaphore.Wait() is called, if another thread can cause a signal to
+ // be generated
// can 'remember' signals the race condition will not occur
// wait ( if necessary ) and decrement semaphore
// can 'remember' signals the race condition will not occur
// wait ( if necessary ) and decrement semaphore
- // 'waiting' thread timesout, and returns from WaitForSingleObject, but
- // has not yet decremented 'nwaiters'.
+ // 'waiting' thread times out, and returns from WaitForSingleObject,
+ // but has not yet decremented m_numWaiters
//
// at this point if another thread calls signal() then the semaphore
// will be incremented, but the waiting thread will miss it.
//
// to handle this particular case, the waiting thread calls
// WaitForSingleObject again with a timeout of 0, after locking
//
// at this point if another thread calls signal() then the semaphore
// will be incremented, but the waiting thread will miss it.
//
// to handle this particular case, the waiting thread calls
// WaitForSingleObject again with a timeout of 0, after locking
// timeout, but will allow the waiting thread to catch the missed
// signals.
wxCriticalSectionLocker lock(m_csWaiters);
// timeout, but will allow the waiting thread to catch the missed
// signals.
wxCriticalSectionLocker lock(m_csWaiters);