Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting... Please check out the Community Guidelines in the
Announcements and Administration Category, below.

Are Dpcs and IRPs serialized?

Two questions here, one about Dpc and the other about IRP.

(1) Can a driver have two CustomDpc functions running at the same time? I realize that since they run at DISPATCH_LEVEL, they will be serialized on the same processor. But what about different processors?

My guess is that they are not serialized, and so can run concurrently on different processors. That would mean that the routines need to use some synchronization method to serialize access to critical data.

But before I put this synchronization into the Dpc routines, I thought I'd see if the routines themselves run serially across all processors.

(2) What happens when one user thread initiates IRP 1, and another thread initiates IRP 2 while IRP 1 is not yet completed? When is the driver's dispatch routine for IRP 2 called? Does the IoManager serialize the dispatch routine calls across all processors?

I want to provide exclusive access to a shared device by having Acquire and Release IOCTLs. I plan to have the Acquire function post the IRP with DEVICE_BUSY if another Acquire is in effect, rather than put the calling thread in a wait state. It would be nice if the IOCTL dispatch calls run serially, so that I don't have to worry about synchronization issues.

Comments

  • Tim_RobertsTim_Roberts Posts: 12,566
    On Feb 17, 2018, at 5:19 PM, xxxxx@rolle.name <xxxxx@lists.osr.com> wrote:
    >
    > Two questions here, one about Dpc and the other about IRP.
    >
    > (1) Can a driver have two CustomDpc functions running at the same time? I realize that since they run at DISPATCH_LEVEL, they will be serialized on the same processor. But what about different processors?
    >
    > My guess is that they are not serialized, and so can run concurrently on different processors. That would mean that the routines need to use some synchronization method to serialize access to critical data.

    Correct. You do have the option of forcing your DPC into a specific processor using KeSetTargetProcessorDpc. Whether that's more or less trouble than synchronization is debatable; most sync needs are pretty simple.


    > (2) What happens when one user thread initiates IRP 1, and another thread initiates IRP 2 while IRP 1 is not yet completed? When is the driver's dispatch routine for IRP 2 called? Does the IoManager serialize the dispatch routine calls across all processors?

    The I/O manager does no serialization at all. If the receiving driver happens to use StartIo or a KMDF serial queue, those will do serialization, but it's all inside the driver.


    > I want to provide exclusive access to a shared device by having Acquire and Release IOCTLs. I plan to have the Acquire function post the IRP with DEVICE_BUSY if another Acquire is in effect, rather than put the calling thread in a wait state. It would be nice if the IOCTL dispatch calls run serially, so that I don't have to worry about synchronization issues.

    Well, that's a trivially easy synchronization problem -- a simple InterlockedExchange would do it.

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

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Mark_RoddyMark_Roddy Posts: 4,262
    If you are using KMDF you can have KMDF impose the serialization you want
    for IOCTLs.

    Mark Roddy

    On Sat, Feb 17, 2018 at 11:25 PM, xxxxx@probo.com
    wrote:

    > On Feb 17, 2018, at 5:19 PM, xxxxx@rolle.name wrote:
    > >
    > > Two questions here, one about Dpc and the other about IRP.
    > >
    > > (1) Can a driver have two CustomDpc functions running at the same time?
    > I realize that since they run at DISPATCH_LEVEL, they will be serialized on
    > the same processor. But what about different processors?
    > >
    > > My guess is that they are not serialized, and so can run concurrently on
    > different processors. That would mean that the routines need to use some
    > synchronization method to serialize access to critical data.
    >
    > Correct. You do have the option of forcing your DPC into a specific
    > processor using KeSetTargetProcessorDpc. Whether that's more or less
    > trouble than synchronization is debatable; most sync needs are pretty
    > simple.
    >
    >
    > > (2) What happens when one user thread initiates IRP 1, and another
    > thread initiates IRP 2 while IRP 1 is not yet completed? When is the
    > driver's dispatch routine for IRP 2 called? Does the IoManager serialize
    > the dispatch routine calls across all processors?
    >
    > The I/O manager does no serialization at all. If the receiving driver
    > happens to use StartIo or a KMDF serial queue, those will do serialization,
    > but it's all inside the driver.
    >
    >
    > > I want to provide exclusive access to a shared device by having Acquire
    > and Release IOCTLs. I plan to have the Acquire function post the IRP with
    > DEVICE_BUSY if another Acquire is in effect, rather than put the calling
    > thread in a wait state. It would be nice if the IOCTL dispatch calls run
    > serially, so that I don't have to worry about synchronization issues.
    >
    > Well, that's a trivially easy synchronization problem -- a simple
    > InterlockedExchange would do it.
    > —
    > Tim Roberts, xxxxx@probo.com
    > Providenza & Boekelheide, Inc.
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at: showlists.cfm?list=ntdev>
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    > software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer>;
    >
  • <quote>
    I plan to have the Acquire function post the IRP with
    DEVICE_BUSY if another Acquire is in effect, rather than put the calling thread
    in a wait state.
    </quote>

    Do you mean COMPLETE the IRP with STATUS_DEVICE_BUSY? If so, then... yeah. Just do that.

    But as Mr. Roddy implied... you PROBABLY shouldn't be doing this with IRPs at all. You *probably* should be using WDF, in which case what you want to do would (probably) be easier.

    Peter
    OSR
    @OSRDrivers

    Peter Viscarola
    OSR
    @OSRDrivers

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!