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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost