If a filter driver with a worker thread had to maintain a spinlock while handling an IRP in the worker thread (until sent down the stack) then would there be any benefit to having a worker thread at all?
TIA!!
What else are you doing in the thread? O find that many new driver writers thibk they need dedicated threads because that is what they have in their apps, but more than likely you can handle everything async in dpcs and completion routines or in the context of the calling thread
d
debt from my phone
From: xxxxx@terabyteunlimited.com
Sent: 1/11/2012 11:17 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] filter driver worker thread and spinlock
If a filter driver with a worker thread had to maintain a spinlock while handling an IRP in the worker thread (until sent down the stack) then would there be any benefit to having a worker thread at all?
TIA!!
NTDEV is sponsored by OSR
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
It’s actually converting one (disk filter) that has extended for several years and did all it’s initial processing in the dispatch routine (look up data in array via binary search and then loop calling another function (if needed) to look up data in a couple other array’s (again binary search) creating any IRP read requests as needed (and update array when needing to add or remove items) where the read completion routine would issue IRP for writing where that completion routine would update value in array then release the original IRP once all of the other IRP’s based on it were completed.) After the loop of setting up the IRP read requests the main dispatch returned status pending (unless it saw all existing irp’s were already completed in which case it released the original at that point). The problem is that certain systems may see some noticeable slow down when it was active (and some storage drivers dead-lock (particularly where hundreds of the original pending IRP’s are released all about the same time) - about 7 years ago nvidia had one but was corrected and went away until now in the past year or so a couple Intel and HP storage drivers are dead locking (for HP only on Win2k8 R2) (MS drivers never deadlock), so just getting around to making an adjustment to see if I can take care of any performance issues that some systems may see (really not a problem on 90% of the systems) and perhaps help prevent those storage drivers from deadlocking (from experience with the nvidia driver, they still deadlock without the filter driver, just maybe a couple times a year). So I was going to basically setup a worker thread, and move most of it to the worker thread so the dispatching wasn’t held up, but if I have to create a spin lock for most of the process (which elevates the thread to dispatch level (from what I read)), I wondered if there would be any benefit (io manger able to send more stuff down or ??).
I went back and refreshed myself on how all this works. I don’t think adding a worker thread would do anything in this case. Much better to hold spinlocks for shorter time if possible.