You’re missing the OP’s point… which I grant you is pretty darn difficult to determine.
OP: You’re attempting to serialize the ordering of log entries across multiple processors, right? So that the log entry for event X appears in the log prior to the log entry for event X+1 ? Is that correct?
And the functions that call your log package all run at IRQL PASSIVE_LEVEL?
I suspect you’re out-thinking yourself on this one.
IF that’s what you’re saying, there is no way to guarantee that the logging will be strictly in order. You can surely see this yourself: Suppose the code running on Thread1 calls your log function, but before the function can run, that thread is pre-empted… now code running on Thread2 runs, calls your log function, finishes, and only THEN does Thread1 resume running. Result, the event Thread2’s info is logged before Thead1’s… out of order.
There is *really* no way to prevent this.
The best you’re going to be able to do is “pretty much in order” no matter what you do… except…
If you want to bump *all* the processing up to IRQL DISPATCH_LEVEL, including the functions that call the logger, THEN you can be sure that items will be logged in-order… and THEN you have to serialize the queue using a Spin Lock as Mr. Shaktskih suggests.
If you’re willing to accept “pretty much in order”, what you do is tag the log queue entry IMMEDIATELY on entry with something that implies order. You this either by calling InterlockedIncrement immediately to get a strictly increasing “queue entry number” value, or reserving a slot in a queue for your log information. In this way, your log entries will be guaranteed to be in the correct order… as defined by the order in which the logging function allocates their tags.
THEN you can insert them in some sort of list, using whatever locking primitive you want (like a spin lock).
I dunno… maybe I have your use case entirely wrong. In which case I need to read more closely or drink more coffee…
BTW, you should know that WPP messages are *not* guaranteed to be in order (or, at least they weren’t back when I was working with the guy who invented it). So, it’s not like this is a solvable problem.
Peter
OSR
@OSRDrivers