Re: [ntdev] Using spin locks for serialization

Further to Peter’s points, any algorithm on an SMP machine under any multi-threaded OS suffers from the limitation that events generated from threads running in parallel can be logged out of order with respect to the wall clock time at which they occurred

Once you get over this logical difficulty, you realize that the log temporal consistency is often important only with respect to specific a thread, task or work item (however the design dictates) and that that in and of itself validates the mostly in order model as sufficient as secondary guarantees of temporal location govern the problem space (ie all of the log entries for a particular request are logged by a single thread, so they must be in order - regardless of whether other threads might have intervened with other unrelated messages). Whether a single thread handles the request or not, correct synch around its data structures and status will tend to ensue (again with no positive guarantee)

Sent from Surface Pro

From: xxxxx@osr.com
Sent: ‎Wednesday‎, ‎October‎ ‎29‎, ‎2014 ‎9‎:‎32‎ ‎AM
To: Windows System Software Devs Interest List

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


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

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