Hi All,
I have a code block in my driver which is called at PASSIVE_LEVEL and needs to be guarded across multiple threads. In addition, inside that code block I have functions that only work at PASSIVE_LEVEL and cant work at raised IRQL. From what I have read over MSDN, looks like the most efficient way to do this is using fast-mutex+criticalregion like below:
KeEnterCriticalRegion()
ExAcquireFastMutexUnsafe(&mutex)
ExReleaseFastMutexUnsafe(&mutex)
KeLeaveCriticalRegion()
Another point to worth consider here is my code block can take upto 2-20 millisecs. If I see the documentation of critical-region, it says:
“Any caller of KeEnterCriticalRegion should call KeLeaveCriticalRegion as quickly as possible after entering a critical region.”
So have below questions:
1. Does anyone knows what are duration constraints here ? For example in spinlock documentation its clearly written that noone should acquire spinlock for more than 25 microsecs. Specifically I want to know whether what I am doing looks fair even if I take 2-20msecs inside critical region.
2. When APCs are blocked via CriticalRegion(), is it blocked only for this thread or system-wide, so that even threads executed by other CPU cores wont be able to process APCs ?
On Thu, 10 Dec 2015, xxxxx@gmail.com wrote:
“Any caller of KeEnterCriticalRegion should call KeLeaveCriticalRegion as quickly as possible after entering a critical region.”
That is a documentation bug, the critical region only affects the caller
and you know if there are any urgent APC’s to run and how urgent they
are.
Bo Branten
Thanks Branten. Can someone from MSFT can comment on it ?
I have seen on one thread Doron told that KeEnter/LeaveCriticalRegion calls are extremely cheap and prevent the APCs from coming.
> I have a code block in my driver which is called at PASSIVE_LEVEL and needs to be guarded
across multiple threads. In addition, inside that code block I have functions that only work at
PASSIVE_LEVEL and cant work at raised IRQL.
I would rework the code to avoid calling these functions under any lock.
After this, just use FAST_MUTEX.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
Thanks Maxim. Whatever you said does make sense and do-able. But it looked to make my code having more overhead, so was thinking to avoid if possible and keep it simple.
Specifically I am interested in knowing answer to 2 questions regarding KeEnterCriticalRegion() which I posted.
- no really there are no specific duration limits other than the
consequences of delaying apcs on this thread.
- it only affects the calling thread.
The doc should have that dire and ambiguous warning deleted.
Mark Roddy
On Thu, Dec 10, 2015 at 4:22 PM, wrote:
> Thanks Maxim. Whatever you said does make sense and do-able. But it looked
> to make my code having more overhead, so was thinking to avoid if possible
> and keep it simple.
>
> Specifically I am interested in knowing answer to 2 questions regarding
> KeEnterCriticalRegion() which I posted.
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
></http:>
We talked about critical regions in the latest issue of The NT Insider:
https://www.osr.com/nt-insider/2015-issue3/critical-regions/
This might answer your questions.
-scott
OSR
@OSRDrivers