thraed wake-up latencies

NTDEV
1

I have a write dispatch routine where I mark the IRP pending and trigger
an event to a thread that is waiting to do the write request that will
interact with the hardware. Without doing this (interaction with the
hardware) in a different thread it could be done in the dispatch routine
while the dedicated thread offers me some other advantage like write
request timeout management. The thread is created during opening of the
device. The write dispatch routine returns right after triggering the
event. I would like to know what could be the latencies between
triggering an event at PASSIVE_LEVEL and waking up the thread? This may
bring up other issues though. What should be the design consideration or
trade-off in this case? Should such usage of thread be avoided?

Thanks,
Hablu

2

The latency can be nearly arbitrary, I would not rely on it.

Use a state-machine-based approach in your driver without any
threads - the state machine is a set of functions which are invoked on
a) app’s actions - from dispatch routine b) timeouts - from timer DPC
c) device interrupts - from DpcForIsr.

Max

----- Original Message -----
From:
To: “NT Developers Interest List”
Sent: Tuesday, February 11, 2003 10:06 PM
Subject: [ntdev] thraed wake-up latencies

> I have a write dispatch routine where I mark the IRP pending and
trigger
> an event to a thread that is waiting to do the write request that
will
> interact with the hardware. Without doing this (interaction with the
> hardware) in a different thread it could be done in the dispatch
routine
> while the dedicated thread offers me some other advantage like write
> request timeout management. The thread is created during opening of
the
> device. The write dispatch routine returns right after triggering
the
> event. I would like to know what could be the latencies between
> triggering an event at PASSIVE_LEVEL and waking up the thread? This
may
> bring up other issues though. What should be the design
consideration or
> trade-off in this case? Should such usage of thread be avoided?
>
> Thanks,
> Hablu
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

3

Thanks for your hints. Some more info:

I don’t have any ISR, device is a network device and the write request is
by TDI interface. I fire up time-out DPC before triggerring the event. I
am trying to mimic the ISR routine by waking up the thread. In the thread
for write I have TDI (TCP)write request. I have separated it from dispacth
routine because I can’t cancel the TDI send request right away when the
timeout for write happens. When TDI send is complete I complete write IRP,
reinitialize timeout and check write queue and start if there there is
any.

-Hablu

The latency can be nearly arbitrary, I would not rely on it.

Use a state-machine-based approach in your driver without any
threads - the state machine is a set of functions which are invoked on
a) app’s actions - from dispatch routine b) timeouts - from timer DPC
c) device interrupts - from DpcForIsr.

Max

----- Original Message -----
From:
> To: “NT Developers Interest List”
> Sent: Tuesday, February 11, 2003 10:06 PM
> Subject: [ntdev] thraed wake-up latencies
>
>
> > I have a write dispatch routine where I mark the IRP pending and
> trigger
> > an event to a thread that is waiting to do the write request that
> will
> > interact with the hardware. Without doing this (interaction with the
> > hardware) in a different thread it could be done in the dispatch
> routine
> > while the dedicated thread offers me some other advantage like write
> > request timeout management. The thread is created during opening of
> the
> > device. The write dispatch routine returns right after triggering
> the
> > event. I would like to know what could be the latencies between
> > triggering an event at PASSIVE_LEVEL and waking up the thread? This
> may
> > bring up other issues though. What should be the design
> consideration or
> > trade-off in this case? Should such usage of thread be avoided?
> >
> > Thanks,
> > Hablu
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >