SpinLock in DPC and IOCTL

Discussion in 'Windows Vista Drivers' started by Avi Lousky, Dec 1, 2007.

  1. Avi Lousky

    Avi Lousky Guest

    I use a spin lock to synch my IOCTLs (which can be called from several user
    mode clients), and my DPC. How will the system behave in the next scenario:
    IOCTL xxx has been called, and starts to run in PASSIVE_LEVEL and aquires
    spin lock MyLock.
    During its excecution, an interrupt has been triggered by the hardware, and
    a DPC starts to run in DISPATCH_LEVEL, aquiring MyLock.
    Will it waits to MyLock to be released (which means that DPC waits for IOCTL
    to be completed) or will it run ignoring the lock (because its in higher
    Avi Lousky, Dec 1, 2007
    1. Advertisements

  2. Avi Lousky

    Don Burn Guest

    Once you have acquired a spin lock you run at DISPATCH_LEVEL, so both your
    DPC and your code you protect run at the same IRQL. If it turns out that
    both run on different processors, the one that trys to get the lock second
    spins (hence the name) in a piece of code testing for the lock to be

    Don Burn (MVP, Windows DDK)
    Windows 2k/XP/2k3 Filesystem and Driver Consulting
    Website: http://www.windrvr.com
    Blog: http://msmvps.com/blogs/WinDrvr
    Remove StopSpam to reply
    Don Burn, Dec 1, 2007
    1. Advertisements

  3. Avi Lousky

    Avi Lousky Guest

    Thank you for your prompt (and productive) answer.
    Avi Lousky, Dec 2, 2007
  4. When PASSIVE_LEVEL code acquires a spinlock, it raises to DISPATCH_LEVEL.
    This blocks DPC delivery on this CPU till the IRQL will be lowered (by
    releasing a spinlock).

    Spinlock itself (its interlocked memory location) guards against DPCs _on
    other CPUs_.
    Maxim S. Shatskih, Dec 2, 2007
  5. Avi Lousky

    David Craig Guest

    Spinlocks do not guard against any DPC on another CPU, but are used to stop
    the same DPC from running on another CPU. That also include any other DPC
    or even PASSIVE_LEVEL or APC_LEVEL code that needs to acquire the same

    For the OP: If you want to force IoCtls to be processed sequentially, the
    use of a spinlock is major overkill and will most likely decrease system
    performance significantly. Look at the code in the floppy and fdc drivers.
    All requests including reads and writes that require access to the floppy
    drive are placed in a work queue that is serviced by only one thread.
    Grabbing a spinlock to prevent data corruption between a DPC and IoCtl code
    should be done for the shortest time possible. Maybe the IoCtl processing
    code should prepare a local copy of the data that needs to be updated and
    after obtaining the spinlock update it as quickly as possible. As Peter
    Viscarola says, you should hold a spinlock for as long as you need it.
    However, do design your code to minimize the amount of time a spinlock is
    David Craig, Dec 2, 2007
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.