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.