I’m unsure whether I can use a system worker thread or if I need to create
my own thread in my driver. I intend to have a worker thread wait for 30
seconds then attempt to delete a device that I have open, so its execution
will last right around 30 seconds total. The WDK documentation (6000) had a
warning and said that if a driver requires “long periods of delayed
processing” it should use PsCreateSystemThread to make its own thread
instead of using a worker thread. Is 30 seconds considered “long” in this
context or will it be ok to use a system worker thread?
IMHO, that is considered to be long, but that’s just me…
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Matthew Carter
Sent: Wednesday, June 27, 2007 12:31 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] How long is “long” for a system worker thread?
I’m unsure whether I can use a system worker thread or if I need to
create
my own thread in my driver. I intend to have a worker thread wait for
30
seconds then attempt to delete a device that I have open, so its
execution
will last right around 30 seconds total. The WDK documentation (6000)
had a
warning and said that if a driver requires “long periods of delayed
processing” it should use PsCreateSystemThread to make its own thread
instead of using a worker thread. Is 30 seconds considered “long” in
this
context or will it be ok to use a system worker thread?
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
30 seconds is surely ‘long’. Creating your own system thread is pretty
trivial. Deadlocks are generally associated with the higher priority
worker threads.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Matthew Carter
Sent: Wednesday, June 27, 2007 3:31 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] How long is “long” for a system worker thread?
I’m unsure whether I can use a system worker thread or if I need to
create
my own thread in my driver. I intend to have a worker thread wait for
30
seconds then attempt to delete a device that I have open, so its
execution
will last right around 30 seconds total. The WDK documentation (6000)
had a
warning and said that if a driver requires “long periods of delayed
processing” it should use PsCreateSystemThread to make its own thread
instead of using a worker thread. Is 30 seconds considered “long” in
this
context or will it be ok to use a system worker thread?
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
PsCreateSystemThread it is then. It is not too difficult, but there doesn’t
seem to be any documentation in the WDK (6000) about PKSTART_ROUTINE or
KSTART_ROUTINE to tell you the proper declaration or operation of the custom
thread procedure, although there is documentation for PsCreateSystemThread
itself. Luckily, it’s works pretty much the same as ThreadProc used in the
SDK and I located the definition of the PKSTART_ROUTINE in wdm.h.
“Roddy, Mark” wrote in message news:xxxxx@ntdev…
30 seconds is surely ‘long’. Creating your own system thread is pretty
trivial. Deadlocks are generally associated with the higher priority
worker threads.
Matthew Carter wrote:
PsCreateSystemThread it is then. It is not too difficult, but there doesn’t
seem to be any documentation in the WDK (6000) about PKSTART_ROUTINE or
KSTART_ROUTINE to tell you the proper declaration or operation of the custom
thread procedure, although there is documentation for PsCreateSystemThread
itself. Luckily, it’s works pretty much the same as ThreadProc used in the
SDK and I located the definition of the PKSTART_ROUTINE in wdm.h.
You know, if it were me, I’d be tempted to create a KTIMER and handle
things in that callback, rather than creating a thread and doing a
delay. Is there a reason you discarded that option?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> You know, if it were me, I’d be tempted to create a KTIMER and handle
things in that callback, rather than creating a thread and doing a
delay. Is there a reason you discarded that option?
I had started out with a KTIMER that activated a DPC and I was closing the
device in the DPC, but I’m trying to add some code in that also calls
IoUnregisterPlugPlayNotification. That function requires passive level but
DPCs run at dispatch level. Threads created by PsCreateSystemThread on the
other hand run at passive level. My understanding is that its ok to raise
the irql but not to lower it beyond where it started a procedure, so it
seemed to me that I’d either have to call a work item from the DPC to get
back into passive mode to handle the IoUnregisterPlugPlayNotification,
leaving me with two routines to worry about (dpc and worker thread) to
perform the task, or I could just create a system thread and have it wait on
a KTIMER event without a dpc, then do the stuff I needed to do all in one
routine at passive level. It seemed easier to understand the code the
latter way.
I haven’t discarded any options at this point. I’m trying to see what can
be done to accomplish my goal in as straightforward a manner as possible.
The IoUnregisterPlugPlayNotification itself is some hocus pocus designed to
try to coerce the PnP manager to unload my driver and I don’t even know if
it will work, but I know it has to be done at a time after I have closed
other devices so I need it to wait then execute and I need at least that
part of the code to execute at passive level, though deleting the device can
be done at dispatch level if necessary.
IoDeleteDevice can only be called at PASSIVE_LEVEL as well (even though
you might not bugcheck if you do it at dispatch)
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Matthew Carter
Sent: Wednesday, June 27, 2007 4:41 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] How long is “long” for a system worker thread?
You know, if it were me, I’d be tempted to create a KTIMER and handle
things in that callback, rather than creating a thread and doing a
delay. Is there a reason you discarded that option?
I had started out with a KTIMER that activated a DPC and I was closing
the
device in the DPC, but I’m trying to add some code in that also calls
IoUnregisterPlugPlayNotification. That function requires passive level
but
DPCs run at dispatch level. Threads created by PsCreateSystemThread on
the
other hand run at passive level. My understanding is that its ok to
raise
the irql but not to lower it beyond where it started a procedure, so it
seemed to me that I’d either have to call a work item from the DPC to
get
back into passive mode to handle the IoUnregisterPlugPlayNotification,
leaving me with two routines to worry about (dpc and worker thread) to
perform the task, or I could just create a system thread and have it
wait on
a KTIMER event without a dpc, then do the stuff I needed to do all in
one
routine at passive level. It seemed easier to understand the code the
latter way.
I haven’t discarded any options at this point. I’m trying to see what
can
be done to accomplish my goal in as straightforward a manner as
possible.
The IoUnregisterPlugPlayNotification itself is some hocus pocus designed
to
try to coerce the PnP manager to unload my driver and I don’t even know
if
it will work, but I know it has to be done at a time after I have closed
other devices so I need it to wait then execute and I need at least that
part of the code to execute at passive level, though deleting the device
can
be done at dispatch level if necessary.
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
>IoDeleteDevice can only be called at PASSIVE_LEVEL as well (even though
you might not bugcheck if you do it at dispatch)
Ahh yes, you are correct. The documentation says <= APC_LEVEL. Thanks for
pointing that out.
Doing a worker thread is very easy. There is an article in the NT Insider
from about 1998 that discusses both the system threads and creating your
own. It doesn’t take much to handle them. I found it very easy to create
them and destroy them when unloading the driver. All you need is the
PsCreateSystemThread, ObReferenceObjectByHandle, PsTerminateThread, and
optionally create a work item and an event for the worker thread to wait on
if you want to keep it running while it waits for something to do.
–
David J. Craig
Engineer, Sr. Staff Software Systems
Broadcom Corporation
“Matthew Carter” wrote in message news:xxxxx@ntdev…
> >IoDeleteDevice can only be called at PASSIVE_LEVEL as well (even though
>>you might not bugcheck if you do it at dispatch)
>
> Ahh yes, you are correct. The documentation says <= APC_LEVEL. Thanks
> for pointing that out.
>
>
>