- Fixed a deadlock - if a thread releasing an fmutex was rescheduled after

checking for contention but before setting the count to one then a thread
trying to acquire the fmutex between the two could be stuck forever even
though the fmutex was actually available.

svn path=/trunk/; revision=5091
This commit is contained in:
David Welch 2003-07-12 01:09:10 +00:00
parent 719ae2a6dd
commit e41f7f3329

View file

@ -16,7 +16,7 @@
* along with this program; if not, write to the Free Software * along with this program; if not, write to the Free Software
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/ */
/* $Id: fmutex.c,v 1.19 2003/07/10 06:27:13 royce Exp $ /* $Id: fmutex.c,v 1.20 2003/07/12 01:09:10 dwelch Exp $
* *
* PROJECT: ReactOS kernel * PROJECT: ReactOS kernel
* FILE: ntoskrnl/ex/fmutex.c * FILE: ntoskrnl/ex/fmutex.c
@ -63,11 +63,11 @@ ExReleaseFastMutexUnsafe(PFAST_MUTEX FastMutex)
{ {
assert(FastMutex->Owner == KeGetCurrentThread()); assert(FastMutex->Owner == KeGetCurrentThread());
FastMutex->Owner = NULL; FastMutex->Owner = NULL;
InterlockedExchange(&FastMutex->Count, 1);
if (FastMutex->Contention > 0) if (FastMutex->Contention > 0)
{ {
KeSetEvent(&FastMutex->Event, 0, FALSE); KeSetEvent(&FastMutex->Event, 0, FALSE);
} }
InterlockedExchange(&FastMutex->Count, 1);
} }
/* EOF */ /* EOF */