[boost] Re: [Boost.Thread] mutex Win32 implementation changes

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2004-07-19 12:15:13

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.