mirror of
https://github.com/reactos/reactos.git
synced 2024-12-27 17:44:45 +00:00
- 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:
parent
719ae2a6dd
commit
e41f7f3329
1 changed files with 2 additions and 2 deletions
|
@ -16,7 +16,7 @@
|
|||
* along with this program; if not, write to the Free Software
|
||||
* 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
|
||||
* FILE: ntoskrnl/ex/fmutex.c
|
||||
|
@ -63,11 +63,11 @@ ExReleaseFastMutexUnsafe(PFAST_MUTEX FastMutex)
|
|||
{
|
||||
assert(FastMutex->Owner == KeGetCurrentThread());
|
||||
FastMutex->Owner = NULL;
|
||||
InterlockedExchange(&FastMutex->Count, 1);
|
||||
if (FastMutex->Contention > 0)
|
||||
{
|
||||
KeSetEvent(&FastMutex->Event, 0, FALSE);
|
||||
}
|
||||
InterlockedExchange(&FastMutex->Count, 1);
|
||||
}
|
||||
|
||||
/* EOF */
|
||||
|
|
Loading…
Reference in a new issue