Peter Dimov wrote:
>  
>  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_ );

Nah, it suspends right before it.

>  
>  >      t4: thread A locks the mutex, decrements refcount to 0,
>  >          unlocks the mutex, and destroys it (including event);
>  
>      CloseHandle( e_ );

and operator delete() [with subsequent "unmap"].

>  
>  >      t5: thread B goes BOOM.
>  
>  Does it? The Win32 kernel is pretty resilient. ;-) We'll have to try it, I
>  guess.

First problem is access to freed memory. But even of you save 
event handle on the stack, you risk to break something because
the same handle might now point to a new event object... in 
something that can't handle spurious wakes on it.

regards,
alexander.

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