KeAcquire/ReleaseDispatcherDatabaseLock do not work properly. Synchronization primatives will sometimes break the kernel, third party drivers, and user mode programs.

BACKGROUND INFORMATION:

The Wait parameter for the dispatcher lock acquire/release functions is
intended to support the Wait parameter in KeSetEvent, KeReleaseSemaphore,
KeReleaseMutant, KeReleaseMutex, etc.

PROBLEM:

The Wait parameter is intended to make the above functions return with the
dispatcher lock still held if the parameter is set to TRUE. The intention
being that KeWaitFor*Object* will be called shortly afterwards, to perform a
set-and-wait operation atomically (additionally, this slightly increases
performance by eliminating redundant spinlock operations). However, because
these functions do not correctly ensure that the dispatcher database lock is
still held when functions like KeSetEvent, KeReleaseSemaphore, KeReleaseMutant,
or KeReleaseMutex return, a context switch may occur before the following wait
operation is executed. This conflicts with the documented behavior of the
above functions, which states that no context switch may occur between the
function call and the following wait operation, given that the Wait parameter
was set to TRUE.

APPLICATIONS POTENTIALLY AFFECTED BY PROBLEM:

Note that the use of the Wait parameter is documented in the DDK for the above
functions, so it is safe to assume that third party drivers may use it.
Additionally, note that the Win32 SignalObjectAndWait API uses the set-and-keep-
dispatcher-lock functionality (exposed through NtSignalAndWaitForSingleObject),
so it is also safe to assume that some Win32 programs will depend on this
functionality as well.

IMPACT OF PROBLEM ON AFFECTED APPLICATIONS:

The impact of this not working is that the atomicity of set-and-wait
synchronization operations is broken. Thus, race conditions involving setting
and waiting for a synchronization primitive can occur in Win32 programs, third
party drivers, and the kernel itself when these applications depend on the
documented functionality.

SOLUTION TO PROBLEM:

Repair the acquire/release dispatcher lock functions to properly implement this
required behavior. I'm not quite sure how to do this myself, hence my posting
to the list.

MITIGATING FACTORS:

If any existing ReactOS applications do depend on this functionality, it is
unlikely that the problem will exhibit itself often. This problem does not
prevent ReactOS from booting or most tests from running, for instance.