Alexander Terekhov wrote:
With respect to swap_based_mutex_for_windows thing (without pimpl-and-never-destroyed-impl), the problem is that it can go boom in unlock().
void lock() throw() { if (m_lock_status.swap(1, msync::acq)) while (m_lock_status.swap(-1, msync::acq)) m_retry_event.wait(); }
void unlock() throw() { if (m_lock_status.swap(0, msync::rel) < 0) m_retry_event.set(); }
Scenario...
Given: mutex protected refcounting. Two threads, A and B.
t0: thread A locks the mutex and decrements refcount to 2;
t1: thread B does m_lock_status.swap(1, msync::acq) on the fast path and sees 1;
t2: thread A unlocks the mutex (doesn't enter slow path);
t3: thread B does mutex m_lock_status.swap(-1, msync::acq), locks the mutex, decrements refcount to 1, does m_lock_status.swap(0, msync::rel) and enters slow path in unlock();
SetEvent( e_ );
t4: thread A locks the mutex, decrements refcount to 0, unlocks the mutex, and destroys it (including event);
CloseHandle( e_ );
t5: thread B goes BOOM.
Does it? The Win32 kernel is pretty resilient. ;-) We'll have to try it, I guess.