Issue with IRQL

[Pavel_Lebedinsky]

> The Wait option in KeSetEvent is more than just an optimization as it

allows a driver to set an event and wait as an atomic operation so that
the order of execution is guaranteed.

Note that the atomicity guarantee is significantly weaker on win7
(where there is no global dispatcher lock). The raised IRQL will
prevent context switching between the two operations, but you
can't assume that the signaled state of the event will become
visible to other threads only after the current thread begins waiting.

The latest docs explicitly mention this:

Microsoft Learn: Build skills that open doors in your career

===
Although the IRQL disables context switches between the two
calls, these calls cannot reliably be used as the start and end of an
atomic operation. For example, between these two calls, a thread
that is running at the same time on another processor might change
the state of the event object or of the target of the wait.

--
Pavel Lebedinsky/Windows Kernel Test
This posting is provided "AS IS" with no warranties, and confers no rights.

[Daniel_Terhell]

wrote in message news:xxxxx@ntdev…
>>I believe the dispatcher lock is nothing more than a IRQL raise,
>
> Therefore, I think your statement holds true only for UP system…
>

You are right, I should have given this some more thought.

//Daniel

[Peter_Viscarola_OSR]

Note that the atomicity guarantee is significantly weaker on win7
(where there is no global dispatcher lock). The raised IRQL will
prevent context switching between the two operations, but you
can’t assume that the signaled state of the event will become
visible to other threads only after the current thread begins waiting.

Thanks for this. For me, this is easily the most interesting (and perhaps the most useful) thing I’ve read on the list for the past week.

Great comment about a subtle change in a subtle parameter,

Peter
OSR