How to use Mulithreading in Drivers

I just want to know how can be use multithreading in driver .
give me some example or sample if possible. i am new to driver.

Thanks

xxxxx@gmail.com wrote:

I just want to know how can be use multithreading in driver .
give me some example or sample if possible. i am new to driver.

The question doesn’t really have any meaning; a driver is ALWAYS
multithreading. Unlike a process, a driver doesn’t (usually) have any
threads of its own. A driver spends its entire life responding to
stimuli from the outside: PnP requests, power requests, user I/O
requests, timer expirations, interrupts, completions, etc. All of those
things cause parts of your driver code to run for a while and then return.

Because those things are not all coordinated, you will often receive
several requests at once. You have to be able to handle that, by making
sure you use interlocking to make sure you don’t have two routines
trying to update the same data structures at the same time.

This has always been true for drivers. We are, in a sense, pioneers in
multithreading.


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

> I just want to know how can be use multithreading in driver .

give me some example or sample if possible. i am new to driver.

Thanks


NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

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

That is a very broad topic. In general, you have to first understand
three IRQL levels: PASSIVE_LEVEL, DISPATCH_LEVEL, and DIRQL levels, and
what is permissible in each. Then you need to uderstand the means of
transition between them, such entering a spinlock, explicit request to
change IRQL level, interrupts, queuing a DPC, and queuing a workitem (a
special case of multithreading using a built-in thread pool), and, of
course, creating your own system thread. Once you have internalized all
this, you need to understand that each level above PASSIVE_LEVEL has an
upper bound on the time you can spend in it. So if you can’t do everthing
you want in an ISR because you would exceed its tie limit or require
operations forbidden at DIRQL level, then you will need to enqueue a DPC
request to deal with it. If, in turn you can’t complete it wthin the DPC
constraint, or require operations forbidden at DISPATCH_LEVEL, then you
will need to use a driver thread.

It’s probably far more complex than what I’ve described, but until you
understand all the issues in the above paragraph, don’t start to think
about using threads in your driver; you will probably end up with a driver
more complex than it needs to be (I think it was Albert Einstein who said,
IIRC, “A driver needs to be just complex enough to control your device,
but no more complex”) Drivers have a lot of intrinsic complexity; adding
gratuitous complexity (such as multithreading because it is cool) is
always a mistake.

That said, nearly EVERY driver must be aware of concurrency, not because
of using driver threads but because the typical driver usually has to deal
with a MINIMUM of three threads of control: one or more application-level
threads running in te top-level dispatch routines, a DPC (actually, with
enough handwaves you can have multiple DPCs running on multiple cores, for
example, your DPC you requested in your ISR might be running on core 3
while a timer DPC is running on core 0; I’ve never seen that this is
expressly forbidden), and and ISR thread (actually, DPCs and ISRs are not
first-class thread objects; they merely look like separate threads from
the pure concurrency viewpoint). So you cannot avoid concurrecy if you
DON’T use driver threads; their main value is to deal with lengthy
operations or situations in which you need to call functions only
permitted at PASSIVE_LEVEL.

Just let me say that since you’re new to drivers, you do not need to worry
about threads until you need them.
joe