ion@svn.reactos.com wrote:
- Reimplement Fast Mutex implementation in HAL/NT to be compatible with the real implementation. (Fast Mutex needs to raise IRQL).
- Implement ExEnterCriticalRegionAndAcquireFastMutexUnsafe and ExReleaseFastMutexUnsafeAndLeaveCriticalRegion.
- Make win32k use those two new functions so that it can continue running at PASSIVE_LEVEL.
- Remove CcBrokenMutex and use the new APIs instead.
- Implement and export ntoskrnl version of Fast Mutex
- Update headers for new fast-mutex definition and API exports.
- Fix RemoveEntryList in NDK.
- Add exfuncs.h to NDK.
- Fix path in mmtypes.h in NDK to be compatible to how it shoudl be included.
*Modified: trunk/reactos/hal/halx86/generic/fmutex.c* --- trunk/reactos/hal/halx86/generic/fmutex.c 2005-11-19 21:07:25 UTC (rev 19351) +++ trunk/reactos/hal/halx86/generic/fmutex.c 2005-11-19 22:13:35 UTC (rev 19352) +VOID +FASTCALL +ExAcquireFastMutex(PFAST_MUTEX FastMutex)
{
- KeEnterCriticalRegion();
- ExAcquireFastMutexUnsafe(FastMutex);
- KIRQL OldIrql;
- /* Raise IRQL to APC */
- OldIrql = KfRaiseIrql(APC_LEVEL);
- /* Decrease the count */
- if (InterlockedDecrement(&FastMutex->Count))
- {
/* Someone is still holding it, use slow path */FastMutex->Contention++;KeWaitForSingleObject(&FastMutex->Gate,WrExecutive,WaitAny,FALSE,NULL);- }
- /* Set the owner and IRQL */
- FastMutex->Owner = KeGetCurrentThread();
- FastMutex->OldIrql = OldIrql;
}
Hi,
this piece of code is wrong. If we terminating a thread, which waits on something, we do unblock the thread. The thread must check, if it got the lock, if not it must wait again.
- Hartmut