|
|
Boost : |
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.
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk