Delayed execution

Hi,

Can someone help with the question “What is the best way to retry an Irp
after an arbitrary delay”. (NT4)

So far I have been able to come up with 3 methods.

  1. Call KeDelayExecutionTHread with some delay from within
    my completion routine.

  2. Create a WorkItem and have that call a method which calls
    KeDelayExecutionThread

  3. Call KeDelayExecutionThread from within my Dispath routine

I see problems in all these three scenarios.

  1. Not sure about this one, can I “delay” the thread calling my
    completion routine without causing problems ?

  2. This is inaccurate as I can’t control when I actually get called.

  3. This is ok I think, but makes my calls synchronous which is ok for now.

Can alyone suggest the correct approach ?

Thx,
Jos


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

If most of your IRPs need this dealyed execution.
Use the following

  1. Start a recurring timer (KeSetTimerEx).
  2. Maintain an IRP list sorted in order of time to retry.
  3. insert IRP into the list in your completion routine.
  4. retry the IRP from your timer DPC

-Srin.

-----Original Message-----
From: Jos Scherders [mailto:xxxxx@home.nl]
Sent: Tuesday, July 17, 2001 8:52 PM
To: NT Developers Interest List
Subject: [ntdev] Delayed execution

Hi,

Can someone help with the question “What is the best way to retry an Irp
after an arbitrary delay”. (NT4)

So far I have been able to come up with 3 methods.

  1. Call KeDelayExecutionTHread with some delay from within
    my completion routine.

  2. Create a WorkItem and have that call a method which calls
    KeDelayExecutionThread

  3. Call KeDelayExecutionThread from within my Dispath routine

I see problems in all these three scenarios.

  1. Not sure about this one, can I “delay” the thread calling my
    completion routine without causing problems ?

  2. This is inaccurate as I can’t control when I actually get called.

  3. This is ok I think, but makes my calls synchronous which is ok for now.

Can alyone suggest the correct approach ?

Thx,
Jos


You are currently subscribed to ntdev as: xxxxx@nai.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

  1. Your completion routine will be run in an arbitrary thread context, most
    likely at DISPATCH_LEVEL. You cannot assume your are below DISPATCH_LEVEL
    and KeDelayExecutionTHread can only be run <= DISPATCH_LEVE. Unless you set
    the overlapped flag when you do CreateFile, your thread is going to be
    blocked until the IRP completes.
  2. You can delay all you want. So why would you care when you get called? If
    you complete the IRP you don’t queue the work item.
  3. Depends on where you call it in your dispatch routine. If before IRQL >=
    DISPATCH_LEVEL, you would be ok.

Gary G. Little
Staff Engineer
Broadband Storage, Inc.
xxxxx@broadstor.com

-----Original Message-----
From: Jos Scherders [mailto:xxxxx@home.nl]
Sent: Tuesday, July 17, 2001 8:52 PM
To: NT Developers Interest List
Subject: [ntdev] Delayed execution

Hi,

Can someone help with the question “What is the best way to retry an Irp
after an arbitrary delay”. (NT4)

So far I have been able to come up with 3 methods.

  1. Call KeDelayExecutionTHread with some delay from within
    my completion routine.

  2. Create a WorkItem and have that call a method which calls
    KeDelayExecutionThread

  3. Call KeDelayExecutionThread from within my Dispath routine

I see problems in all these three scenarios.

  1. Not sure about this one, can I “delay” the thread calling my
    completion routine without causing problems ?

  2. This is inaccurate as I can’t control when I actually get called.

  3. This is ok I think, but makes my calls synchronous which is ok for now.

Can alyone suggest the correct approach ?

Thx,
Jos


You are currently subscribed to ntdev as: xxxxx@broadstor.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Gary Little wrote:

  1. Your completion routine will be run in an arbitrary thread context, most
    likely at DISPATCH_LEVEL. You cannot assume your are below DISPATCH_LEVEL
    and KeDelayExecutionTHread can only be run <= DISPATCH_LEVE. Unless you set
    the overlapped flag when you do CreateFile, your thread is going to be
    blocked until the IRP completes.

Yes, that was stupid. I can’t use that call so forget this option.

  1. You can delay all you want. So why would you care when you get called? If
    you complete the IRP you don’t queue the work item.

Well, I care because if I want a delay of Xms and I get called after Xms
have passed by I have a problem. But I think the solution is to launch a
DPC using the KeSetTimer() stuff which I overlooked. I think that is the
proper way of doing this or not ?

  1. Depends on where you call it in your dispatch routine. If before IRQL >=
    DISPATCH_LEVEL, you would be ok.

Yes, I get it.

Thx.
Jos


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

That’s what I would do. Set a specified timeout and let the DPC worry about
doing it again or completing it.

Gary G. Little
Staff Engineer
Broadband Storage, Inc.
xxxxx@broadstor.com

-----Original Message-----
From: Jos Scherders [mailto:xxxxx@home.nl]
Sent: Wednesday, July 18, 2001 12:19 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Delayed execution

Gary Little wrote:

  1. Your completion routine will be run in an arbitrary thread context,
    most
    likely at DISPATCH_LEVEL. You cannot assume your are below DISPATCH_LEVEL
    and KeDelayExecutionTHread can only be run <= DISPATCH_LEVE. Unless you
    set
    the overlapped flag when you do CreateFile, your thread is going to be
    blocked until the IRP completes.

Yes, that was stupid. I can’t use that call so forget this option.

  1. You can delay all you want. So why would you care when you get called?
    If
    you complete the IRP you don’t queue the work item.

Well, I care because if I want a delay of Xms and I get called after Xms
have passed by I have a problem. But I think the solution is to launch a
DPC using the KeSetTimer() stuff which I overlooked. I think that is the
proper way of doing this or not ?

  1. Depends on where you call it in your dispatch routine. If before IRQL
    =
    DISPATCH_LEVEL, you would be ok.

Yes, I get it.

Thx.
Jos


You are currently subscribed to ntdev as: xxxxx@broadstor.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Small point but…

“Callers of KeDelayExecutionThread must be running at IRQL = PASSIVE_LEVEL.”

Regards,
Andy

Andrew L Guy
Senior Software Engineer
Aston Electronic Designs Ltd.
Camberley, UK.

Tel: +44 1252 836221
www.aston.tv

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Jos Scherders
Sent: 18 July 2001 08:19
To: NT Developers Interest List
Subject: [ntdev] RE: Delayed execution

Gary Little wrote:

  1. Your completion routine will be run in an arbitrary thread context,
    most
    likely at DISPATCH_LEVEL. You cannot assume your are below DISPATCH_LEVEL
    and KeDelayExecutionTHread can only be run <= DISPATCH_LEVE. Unless you
    set
    the overlapped flag when you do CreateFile, your thread is going to be
    blocked until the IRP completes.

Yes, that was stupid. I can’t use that call so forget this option.

  1. You can delay all you want. So why would you care when you get called?
    If
    you complete the IRP you don’t queue the work item.

Well, I care because if I want a delay of Xms and I get called after Xms
have passed by I have a problem. But I think the solution is to launch a
DPC using the KeSetTimer() stuff which I overlooked. I think that is the
proper way of doing this or not ?

  1. Depends on where you call it in your dispatch routine. If before IRQL
    =
    DISPATCH_LEVEL, you would be ok.

Yes, I get it.

Thx.
Jos


You are currently subscribed to ntdev as: xxxxx@aston.tv
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the system manager.


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

This is said by the DDK, but …
… the logic of the first three Irqls says that it should be possible
to wait at Irql < DISPATCH_LEVEL, so at PASSIVE or APC level.
But assertion in the KeDelayExecution thread says that the routine
also counts with the case the Irql = DISPATCH_LEVEL - the assertion
is: ASSERT(Thread->WaitIrql <= DISPATCH_LEVEL).

If I can say what I would consider as correct - wait at Irql <=
APC_LEVEL.

Paul

PS: I think the DDK is sometimes too restrictive towards the possible
Irql levels,
but the deeper view into the checked build NTOS shows there is no
reason to do so.
Is there someone who shares this feeling with me ?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Andy Guy
Sent: Wednesday, July 18, 2001 9:29 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Delayed execution

Small point but…

“Callers of KeDelayExecutionThread must be running at IRQL =
PASSIVE_LEVEL.”

Regards,
Andy

Andrew L Guy
Senior Software Engineer
Aston Electronic Designs Ltd.
Camberley, UK.

Tel: +44 1252 836221
www.aston.tv

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Jos Scherders
Sent: 18 July 2001 08:19
To: NT Developers Interest List
Subject: [ntdev] RE: Delayed execution

Gary Little wrote:

  1. Your completion routine will be run in an arbitrary thread context,
    most
    likely at DISPATCH_LEVEL. You cannot assume your are below
    DISPATCH_LEVEL
    and KeDelayExecutionTHread can only be run <= DISPATCH_LEVE. Unless
    you
    set
    the overlapped flag when you do CreateFile, your thread is going to be
    blocked until the IRP completes.

Yes, that was stupid. I can’t use that call so forget this option.

  1. You can delay all you want. So why would you care when you get
    called?
    If
    you complete the IRP you don’t queue the work item.

Well, I care because if I want a delay of Xms and I get called after Xms
have passed by I have a problem. But I think the solution is to launch a
DPC using the KeSetTimer() stuff which I overlooked. I think that is the
proper way of doing this or not ?

  1. Depends on where you call it in your dispatch routine. If before
    IRQL
    =
    DISPATCH_LEVEL, you would be ok.

Yes, I get it.

Thx.
Jos


You are currently subscribed to ntdev as: xxxxx@aston.tv
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

This email and any files transmitted with it are confidential and
intended
solely for the use of the individual or entity to whom they are
addressed.
If you have received this email in error please notify the system
manager.


You are currently subscribed to ntdev as: xxxxx@compelson.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

> ----------

From: Pavel Hrdina[SMTP:xxxxx@compelson.com]
Reply To: NT Developers Interest List
Sent: Wednesday, July 18, 2001 10:49 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Delayed execution

PS: I think the DDK is sometimes too restrictive towards the possible
Irql levels,
but the deeper view into the checked build NTOS shows there is no
reason to do so.
Is there someone who shares this feeling with me ?

You’re probably right and it isn’t the only example where DKK is too
restrictive. If you know what you’re doing you can ignore some unnecessary
restrictions (don’t ask me for example, my memory leaked :). On the other
hand, such observations depend on current implementation which may change in
the future. That’s why I try to use DDK recommendations if possible and
break rules only if absolutely necessary (for example if I have to add one
more line of code :).

Best regards,

Michal Vodicka
Veridicom
(RKK - Skytale)
[WWW: http://www.veridicom.com , http://www.skytale.com]


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

>

Well, I care because if I want a delay of Xms and I get called after Xms
have passed by I have a problem. But I think the solution is to launch a
DPC using the KeSetTimer() stuff which I overlooked. I think that is the
proper way of doing this or not ?

Thx.
Jos

If you have to re-submit your IRP after a certain number of milliseconds,
no problem, the timer will take care of this for you, but, if you have to
re-submit this IRP BEFORE a certain number of milliseconds has elapsed you
are in a little more trouble. There is no way to really guarantee this.
The delay is indeterminant, as the timer is guaranteed to kick off after
the desired wait time, but your DPC may run well after that time period.
Your hardware and driver need to be designed to deal with either some lost
IRPs, or times that may stretch out a bit. In my driver I could get in my
DPC and spin for a couple of minutes if I wanted and your driver would be
at my mercy on a single processor machine. There is no way to prevent that
really. Although if I truly did that your driver probably wouldn’t be the
only one on my machine to crap out. But, hopefully you get the point.
Delays are indeterminant.

Also, just as a side point. Your original second solution of using a
WorkItem to call KeDelayExecutionThread looks viable, but it is a really
bad idea to use a work item and then delay like this. This is a really
common mistake, but can wreak havoc on a system, and I have seen this cause
problems. The problem is work items, or more specifically system worker
threads are an extremely limited system resource. Keeping a system worker
thread tied up by running a delay for some large number of milliseconds is
not good. If it is absolutely necessary to use a work item for blocking,
it is best to block for a very short period of time, check if what you are
waiting for has happened, (be that an elapsed time period, or an event, or
whatever), and if not, reshedule the work item and return. This puts your
callback at the back of the queue and lets other system entities have
access to the small pool of system worker threads.

Bill M.


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

> Also, just as a side point. Your original second solution of using a

WorkItem to call KeDelayExecutionThread looks viable, but it is a really
bad idea to use a work item and then delay like this. This is a really

Agree. Daniel Lovinger from MS even suggested to use your own work items on
top of system ExQueueWorkItem due to this reason.

Max


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com