Some doubts about KeStallExecutionProcessor and KeDelayExecutionThread

NTDEV
1

1.KeStallExecutionProcessor is busy wait, is ok?
2.KeDelayExecutionThread can sleep specified time and can be scheduled?
3.I implement some functions to busy wait for MicroSeconds and sleep for MicroSeconds(can be scheduled), is that ok? These functions are :

api_status func_mDelay (ULONG interVal) // busy wait for interVal MicroSeconds
{
KeStallExecutionProcessor(interVal);
return api_OK;
}

DRE_status func_mSchedule (ULONG interVal) //
{
LARGE_INTEGER delayTime;
YieldProcessor(); //give up the processor
delayTime.QuadPart = WDF_REL_TIMEOUT_IN_MS(interVal);
KeDelayExecutionThread(KernelMode, FALSE, &delayTime);
return api_OK;
}

I just want to implement that busy wait for MicroSeconds and Sleep for MicroSeconds (while can give up processor the same time).

2

I believe as far as your current thread is preempted, you give up the processor anyway, right, the dispatcher will schedule another thread. Or, are you asking, what will happen, if you have a processor that supports hyper-threading, and you think that your thread will actually be on the processor with other threads, and do the actual sleeping without being preempted ?

3

Yes.I am not sure that the thread called KeDelayExecutionThread if be preempted when it is sleeping.

4

If I call func_mSchedule(0), in my opinion, the current thread is immediately scheduled that give up processor to other threads, is it write?

5

>1.KeStallExecutionProcessor is busy wait,

Correct - it does not yield the CPU, and, hence, can be called at any IRQL. IIRC, the busy wait itself is always performed at elevated IRQL. This is why you should use this function with care and specify relatively short stall periods (typically a few microseconds)

2.KeDelayExecutionThread can sleep specified time and can be scheduled?

KeDelayExecutionThread() yields the CPU. Therefore, the minimum possible resolution that you can achieve is 1 clock tick. Once this call yields the CPU you can specify long wait periods . However, keep in mind that, once Windows NT is not RTOS, your actual wait can take much longer compared to what you have specified - it depends on the system load and on how calling thread’s priority fares against those of other threads…

Anton Bassov

6

Thanks anton. It seems YieldProcessor() is unnecessary.

7

There is some documentation on this matter, in “Windows Internals 5th or 6th Edition”, the matter Anton mention about the resolution of the timer, that the thread will wait AT LEAST the time mentioned in the LARGE_INTEGER structure, and that time is rounded up actually by the system to a system granularity of some sort. Taking into consideration hardware interrupts, and DPC’s and other software interrupts now you can see how that time period can be bigger.

8

wrote in message news:xxxxx@ntdev…
> 1.KeStallExecutionProcessor is busy wait, is ok?

It is busy wait. Ok.

> 2.KeDelayExecutionThread can sleep specified time and can be scheduled?

Yes

> 3.I implement some functions to busy wait for MicroSeconds and sleep for
> MicroSeconds(can be scheduled), is that ok? These functions are :
>
>
> api_status func_mDelay (ULONG interVal) // busy wait for interVal
> MicroSeconds
> {
> KeStallExecutionProcessor(interVal);
> return api_OK;
> }
>
> DRE_status func_mSchedule (ULONG interVal) //
> {
> LARGE_INTEGER delayTime;
> YieldProcessor(); //give up the processor
> delayTime.QuadPart = WDF_REL_TIMEOUT_IN_MS(interVal);
> KeDelayExecutionThread(KernelMode, FALSE, &delayTime);
> return api_OK;
> }
>
>
> I just want to implement that busy wait for MicroSeconds and Sleep for
> MicroSeconds (while can give up processor the same time).
>

You want YieldProcessor() in the 1st (busy sleep) function, rather than in
the 2nd.
Or better remove it and let Windows do the RIGHT thing,
Also you may want to name these functions func_uDelay and func_uSchedule
because “m” usually stands for milli, and “u” for micro.

Regards,
–pa

9

> 1.KeStallExecutionProcessor is busy wait, is ok?

Yes.

2.KeDelayExecutionThread can sleep specified time and can be scheduled?

Yes, so the minimal delay is a timeslice (10 or 16ms or such).

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

10

xxxxx@yahoo.com.cn wrote:

api_status func_mDelay (ULONG interVal) // busy wait for interVal MicroSeconds
{
KeStallExecutionProcessor(interVal);
return api_OK;
}

DRE_status func_mSchedule (ULONG interVal) //
{
LARGE_INTEGER delayTime;
YieldProcessor(); //give up the processor
delayTime.QuadPart = WDF_REL_TIMEOUT_IN_MS(interVal);
KeDelayExecutionThread(KernelMode, FALSE, &delayTime);
return api_OK;
}

I just want to implement that busy wait for MicroSeconds and Sleep for MicroSeconds (while can give up processor the same time).

Well, in the code as you have implemented it, func_mSchedule actually
delays a number of MILLIseconds, not MICROseconds. If you want
microseconds, you’d need WDF_REL_TIMEOUT_IN_US, but since the resolution
is in whole milliseconds anyway, it’s not clear that it’s very useful.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

11

Well, what you wrote is expected and seems logical but unfortunately,
the reality is different. The thread can wait LESS than specified time
in some cases. Specifically, in the case when the current thread already
consumed part of its quantum and the remaining time is shorter than
specified wait time modulo quantum length. I presume it is because the
quantum length is substracted from wait time on its end and negative
results are taken as zero (haven’t checked).

For example, if you call Sleep(10) and the thread already consumed 14 ms
of current quantum, the real sleep time can be 2 ms. Works equally in
both kernel and user mode and is rather easy to test from a simple app.
I presume some of you may want to test it as it seems unbelievable :slight_smile:

In turn, if something really depends on “at least” waiting, it is
necessary to add quantum length to wait time. That’s exactly what for
example OS USB drivers do to conform with USB specification where are
mandatory delays. As an unwanted side effect USB wakeup is much longer
than necessary in most times…

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Tuesday, August 10, 2010 1:25 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Some doubts about
KeStallExecutionProcessor and KeDelayExecutionThread

There is some documentation on this matter, in “Windows
Internals 5th or 6th Edition”, the matter Anton mention about
the resolution of the timer, that the thread will wait AT
LEAST the time mentioned in the LARGE_INTEGER structure, and
that time is rounded up actually by the system to a system
granularity of some sort. Taking into consideration hardware
interrupts, and DPC’s and other software interrupts now you
can see how that time period can be bigger.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online
at http://www.osronline.com/page.cfm?name=ListServer

12

> The thread can wait LESS than specified time in some cases. Specifically, in the case when

the current thread already consumed part of its quantum and the remaining time is shorter than
specified wait time modulo quantum length.

Apparently you mean not “thread quantum” but “clock tick”, right…

Assuming that there is no thread of priority above or equal to the calling one anywhere around, the above scenario is perfectly logical under these circumstances. The system has no concept of time in between ticks, so that, by specifying shorter than clock tick wait period, the calling thread tells the system that it will be eligible for running upon the next tick…

Anton Bassov

13

> -----Original Message-----

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Wednesday, August 11, 2010 12:15 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Some doubts about
KeStallExecutionProcessor and KeDelayExecutionThread

Apparently you mean not “thread quantum” but “clock tick”, right…

Yes, sorry, I was asleep and used wrong terminology. I meant the time
from sleep function call till the moment when the thread is rescheduled.
Or maybe till current tick ends, I haven’t tested it so much.

Assuming that there is no thread of priority above or equal
to the calling one anywhere around, the above scenario is
perfectly logical under these circumstances. The system has
no concept of time in between ticks, so that, by specifying
shorter than clock tick wait period, the calling thread tells
the system that it will be eligible for running upon the next tick…

I don’t say it isn’t logical. I say it is unexpected and inapparent to
most programmers.

However, this scenario doesn’t occur only when specified time is shorter
than clock tick time. Sleep(10) means sleep for 0 - 16 ms, Sleep(30)
means 16 - 32 ms sleep and so on. Depending on a moment when sleep
function was called.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

14

@Vodicka:

I think that minimal sleep time is guaranteed. If you request 10 ms, it will sleep at least 10 ms. But because there may be no measurement finer than a timer tick, it will sleep at least from one tick to another. Not from a moment between ticks to the next tick.

15

> -----Original Message-----

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@broadcom.com
Sent: Thursday, August 12, 2010 3:01 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Some doubts about
KeStallExecutionProcessor and KeDelayExecutionThread

I think that minimal sleep time is guaranteed. If you request
10 ms, it will sleep at least 10 ms. But because there may be
no measurement finer than a timer tick, it will sleep at
least from one tick to another. Not from a moment between
ticks to the next tick.

Instead of thinking test and measure. You’ll be surprised.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

16

That would be far too sensible a thing to do for this list…

Good afternoon,

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Thursday, August 12, 2010 1:30 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Some doubts about KeStallExecutionProcessor and
KeDelayExecutionThread

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@broadcom.com
Sent: Thursday, August 12, 2010 3:01 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Some doubts about KeStallExecutionProcessor and
KeDelayExecutionThread

I think that minimal sleep time is guaranteed. If you request
10 ms, it will sleep at least 10 ms. But because there may be no
measurement finer than a timer tick, it will sleep at least from one
tick to another. Not from a moment between ticks to the next tick.

Instead of thinking test and measure. You’ll be surprised.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

17

If I didn’t write I measured it and that it is surprising for most
devs… oh well.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of M. M. O’Brien
Sent: Thursday, August 12, 2010 7:36 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Some doubts about
KeStallExecutionProcessor and KeDelayExecutionThread

That would be far too sensible a thing to do for this list…

Good afternoon,

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Thursday, August 12, 2010 1:30 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Some doubts about KeStallExecutionProcessor and
KeDelayExecutionThread

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> xxxxx@broadcom.com
> Sent: Thursday, August 12, 2010 3:01 AM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] Some doubts about KeStallExecutionProcessor and
> KeDelayExecutionThread
>
> I think that minimal sleep time is guaranteed. If you request
> 10 ms, it will sleep at least 10 ms. But because there may be no
> measurement finer than a timer tick, it will sleep at least
from one
> tick to another. Not from a moment between ticks to the next tick.

Instead of thinking test and measure. You’ll be surprised.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online
at http://www.osronline.com/page.cfm?name=ListServer