Intravision/reactos
1
0
Fork 0
mirror of https://github.com/reactos/reactos.git synced 2024-11-20 14:30:57 +00:00
Code Issues Projects Releases Packages Wiki Activity
reactos/ntoskrnl/ex/fmutex.c

104 lines
2 KiB
C
Raw Normal View History

- 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. svn path=/trunk/; revision=19352
2005-11-19 22:13:35 +00:00
/*
Standardize comment headers. Patch by Trevor McCort svn path=/trunk/; revision=13311
2005-01-26 13:58:37 +00:00
* COPYRIGHT: See COPYING in the top level directory
- 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. svn path=/trunk/; revision=19352
2005-11-19 22:13:35 +00:00
* PROJECT: ReactOS Kernel
Initial revision svn path=/trunk/; revision=8
1998-08-25 04:27:26 +00:00
* FILE: ntoskrnl/ex/fmutex.c
* PURPOSE: Implements fast mutexes
- 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. svn path=/trunk/; revision=19352
2005-11-19 22:13:35 +00:00
* PROGRAMMERS: Alex Ionescu (alex@relsoft.net)
Initial revision svn path=/trunk/; revision=8
1998-08-25 04:27:26 +00:00
*/
/* INCLUDES *****************************************************************/
2004-08-15 Casper S. Hornstrup <chorns@users.sourceforge.net> * ntoskrnl/include/.cvsignore: New file. * ntoskrnl/include/ntoskrnl.h: Ditto. * ntoskrnl/*/*.c: Use pre-compiled header. * ntoskrnl/Makefile: Support pre-compiled header. * tools/helper.mk: .pch files are now .gch files. svn path=/trunk/; revision=10550
2004-08-15 16:39:12 +00:00
#include <ntoskrnl.h>
- Call IRP_MN_START_DEVICE in a critical region, since NT drivers depend on this implementation detail (on NT, an ERESOURCE+CriticalRegion is always held when parsing a new device node, so all related IRP_MNs are actually received under a critical region. For now, I only made IRP_MN_START_DEVICE behave as such. i8042prt from the DDK depends on this behavior. - Cleaned up Fast Mutex Implementation. - Disabled a hard-coded bugcheck and instead disabled soem code. svn path=/trunk/; revision=26294
2007-04-09 13:00:38 +00:00
#define NDEBUG
#include <debug.h>
Initial revision svn path=/trunk/; revision=8
1998-08-25 04:27:26 +00:00
- Inline Guarded Mutex and Fast Mutex implementations when called from within the kernel svn path=/trunk/; revision=39214
2009-01-30 16:45:17 +00:00
/* Undefine some macros we implement here */
#undef ExEnterCriticalRegionAndAcquireFastMutexUnsafe
#undef ExReleaseFastMutexUnsafeAndLeaveCriticalRegion
#undef ExAcquireFastMutex
#undef ExReleaseFastMutex
#undef ExAcquireFastMutexUnsafe
#undef ExReleaseFastMutexUnsafe
#undef ExTryToAcquireFastMutex
- Call IRP_MN_START_DEVICE in a critical region, since NT drivers depend on this implementation detail (on NT, an ERESOURCE+CriticalRegion is always held when parsing a new device node, so all related IRP_MNs are actually received under a critical region. For now, I only made IRP_MN_START_DEVICE behave as such. i8042prt from the DDK depends on this behavior. - Cleaned up Fast Mutex Implementation. - Disabled a hard-coded bugcheck and instead disabled soem code. svn path=/trunk/; revision=26294
2007-04-09 13:00:38 +00:00
/* PUBLIC FUNCTIONS **********************************************************/
/*
* @implemented
*/
VOID
FASTCALL
ExEnterCriticalRegionAndAcquireFastMutexUnsafe(IN OUT PFAST_MUTEX FastMutex)
{
- Inline Guarded Mutex and Fast Mutex implementations when called from within the kernel svn path=/trunk/; revision=39214
2009-01-30 16:45:17 +00:00
/* Call the inline */
[NTOSKRNL] spelling fixes only no code changes svn path=/trunk/; revision=67386
2015-04-24 19:40:38 +00:00
_ExEnterCriticalRegionAndAcquireFastMutexUnsafe(FastMutex);
- Call IRP_MN_START_DEVICE in a critical region, since NT drivers depend on this implementation detail (on NT, an ERESOURCE+CriticalRegion is always held when parsing a new device node, so all related IRP_MNs are actually received under a critical region. For now, I only made IRP_MN_START_DEVICE behave as such. i8042prt from the DDK depends on this behavior. - Cleaned up Fast Mutex Implementation. - Disabled a hard-coded bugcheck and instead disabled soem code. svn path=/trunk/; revision=26294
2007-04-09 13:00:38 +00:00
}
/*
* @implemented
*/
VOID
FASTCALL
ExReleaseFastMutexUnsafeAndLeaveCriticalRegion(IN OUT PFAST_MUTEX FastMutex)
{
- Inline Guarded Mutex and Fast Mutex implementations when called from within the kernel svn path=/trunk/; revision=39214
2009-01-30 16:45:17 +00:00
/* Call the inline */
[NTOSKRNL] spelling fixes only no code changes svn path=/trunk/; revision=67386
2015-04-24 19:40:38 +00:00
_ExReleaseFastMutexUnsafeAndLeaveCriticalRegion(FastMutex);
- 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. svn path=/trunk/; revision=19352
2005-11-19 22:13:35 +00:00
}
/*
* @implemented
*/
VOID
FASTCALL
- Call IRP_MN_START_DEVICE in a critical region, since NT drivers depend on this implementation detail (on NT, an ERESOURCE+CriticalRegion is always held when parsing a new device node, so all related IRP_MNs are actually received under a critical region. For now, I only made IRP_MN_START_DEVICE behave as such. i8042prt from the DDK depends on this behavior. - Cleaned up Fast Mutex Implementation. - Disabled a hard-coded bugcheck and instead disabled soem code. svn path=/trunk/; revision=26294
2007-04-09 13:00:38 +00:00
ExAcquireFastMutex(IN OUT PFAST_MUTEX FastMutex)
- 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. svn path=/trunk/; revision=19352
2005-11-19 22:13:35 +00:00
{
- Inline Guarded Mutex and Fast Mutex implementations when called from within the kernel svn path=/trunk/; revision=39214
2009-01-30 16:45:17 +00:00
/* Call the inline */
_ExAcquireFastMutex(FastMutex);
- 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. svn path=/trunk/; revision=19352
2005-11-19 22:13:35 +00:00
}
/*
* @implemented
*/
VOID
FASTCALL
- Call IRP_MN_START_DEVICE in a critical region, since NT drivers depend on this implementation detail (on NT, an ERESOURCE+CriticalRegion is always held when parsing a new device node, so all related IRP_MNs are actually received under a critical region. For now, I only made IRP_MN_START_DEVICE behave as such. i8042prt from the DDK depends on this behavior. - Cleaned up Fast Mutex Implementation. - Disabled a hard-coded bugcheck and instead disabled soem code. svn path=/trunk/; revision=26294
2007-04-09 13:00:38 +00:00
ExReleaseFastMutex(IN OUT PFAST_MUTEX FastMutex)
- 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. svn path=/trunk/; revision=19352
2005-11-19 22:13:35 +00:00
{
- Inline Guarded Mutex and Fast Mutex implementations when called from within the kernel svn path=/trunk/; revision=39214
2009-01-30 16:45:17 +00:00
/* Call the inline */
_ExReleaseFastMutex(FastMutex);
Initial revision svn path=/trunk/; revision=8
1998-08-25 04:27:26 +00:00
}
added @implemented and @unimplemented notes to the cc through fs directories of ntoskrnl svn path=/trunk/; revision=5033
2003-07-10 06:27:13 +00:00
/*
* @implemented
*/
- 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. svn path=/trunk/; revision=19352
2005-11-19 22:13:35 +00:00
VOID
FASTCALL
- Call IRP_MN_START_DEVICE in a critical region, since NT drivers depend on this implementation detail (on NT, an ERESOURCE+CriticalRegion is always held when parsing a new device node, so all related IRP_MNs are actually received under a critical region. For now, I only made IRP_MN_START_DEVICE behave as such. i8042prt from the DDK depends on this behavior. - Cleaned up Fast Mutex Implementation. - Disabled a hard-coded bugcheck and instead disabled soem code. svn path=/trunk/; revision=26294
2007-04-09 13:00:38 +00:00
ExAcquireFastMutexUnsafe(IN OUT PFAST_MUTEX FastMutex)
- 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. svn path=/trunk/; revision=19352
2005-11-19 22:13:35 +00:00
{
- Call IRP_MN_START_DEVICE in a critical region, since NT drivers depend on this implementation detail (on NT, an ERESOURCE+CriticalRegion is always held when parsing a new device node, so all related IRP_MNs are actually received under a critical region. For now, I only made IRP_MN_START_DEVICE behave as such. i8042prt from the DDK depends on this behavior. - Cleaned up Fast Mutex Implementation. - Disabled a hard-coded bugcheck and instead disabled soem code. svn path=/trunk/; revision=26294
2007-04-09 13:00:38 +00:00
/* Acquire the mutex unsafely */
- Inline Guarded Mutex and Fast Mutex implementations when called from within the kernel svn path=/trunk/; revision=39214
2009-01-30 16:45:17 +00:00
_ExAcquireFastMutexUnsafe(FastMutex);
- 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. svn path=/trunk/; revision=19352
2005-11-19 22:13:35 +00:00
}
/*
* @implemented
*/
VOID
FASTCALL
- Call IRP_MN_START_DEVICE in a critical region, since NT drivers depend on this implementation detail (on NT, an ERESOURCE+CriticalRegion is always held when parsing a new device node, so all related IRP_MNs are actually received under a critical region. For now, I only made IRP_MN_START_DEVICE behave as such. i8042prt from the DDK depends on this behavior. - Cleaned up Fast Mutex Implementation. - Disabled a hard-coded bugcheck and instead disabled soem code. svn path=/trunk/; revision=26294
2007-04-09 13:00:38 +00:00
ExReleaseFastMutexUnsafe(IN OUT PFAST_MUTEX FastMutex)
Initial revision svn path=/trunk/; revision=8
1998-08-25 04:27:26 +00:00
{
- Call IRP_MN_START_DEVICE in a critical region, since NT drivers depend on this implementation detail (on NT, an ERESOURCE+CriticalRegion is always held when parsing a new device node, so all related IRP_MNs are actually received under a critical region. For now, I only made IRP_MN_START_DEVICE behave as such. i8042prt from the DDK depends on this behavior. - Cleaned up Fast Mutex Implementation. - Disabled a hard-coded bugcheck and instead disabled soem code. svn path=/trunk/; revision=26294
2007-04-09 13:00:38 +00:00
/* Release the mutex unsafely */
- Inline Guarded Mutex and Fast Mutex implementations when called from within the kernel svn path=/trunk/; revision=39214
2009-01-30 16:45:17 +00:00
_ExReleaseFastMutexUnsafe(FastMutex);
- 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. svn path=/trunk/; revision=19352
2005-11-19 22:13:35 +00:00
}
/*
* @implemented
*/
BOOLEAN
FASTCALL
- Call IRP_MN_START_DEVICE in a critical region, since NT drivers depend on this implementation detail (on NT, an ERESOURCE+CriticalRegion is always held when parsing a new device node, so all related IRP_MNs are actually received under a critical region. For now, I only made IRP_MN_START_DEVICE behave as such. i8042prt from the DDK depends on this behavior. - Cleaned up Fast Mutex Implementation. - Disabled a hard-coded bugcheck and instead disabled soem code. svn path=/trunk/; revision=26294
2007-04-09 13:00:38 +00:00
ExTryToAcquireFastMutex(IN OUT PFAST_MUTEX FastMutex)
- 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. svn path=/trunk/; revision=19352
2005-11-19 22:13:35 +00:00
{
- Inline Guarded Mutex and Fast Mutex implementations when called from within the kernel svn path=/trunk/; revision=39214
2009-01-30 16:45:17 +00:00
/* Call the inline */
return _ExTryToAcquireFastMutex(FastMutex);
Initial revision svn path=/trunk/; revision=8
1998-08-25 04:27:26 +00:00
}
Some STDCALL/FASTCALL added in Ex code. NTOSKRNL's makefile revised with redundant passes removed. svn path=/trunk/; revision=1142
2000-05-01 14:15:03 +00:00
/* EOF */
Reference in a new issue Copy permalink