Does anyone know for certain if KeWaitForSingleObject is multi-processor
safe. In other words, is it SMP safe.

"webman" <webman@discussions.microsoft.com> wrote in message news:332AD265-EAD1-4437-934A-D3FD3DB91C81@microsoft.com...
Nothing is safe in awkward hands... what is your problem?

--PA

I can be more specific, if that will help.

We have a situation where we are using KeWaitForSingleObject() to serialize
several client service requests (as opposed to indications) threads at >
dispatch level. The question then reduces to can different threads on
different processors call this function with the same mutex object and be
assured that one thread won't get swapped out between a read and a set by
another thread doing a read.

More simply put, is KeWaitForSingleObject() SMP safe.

An additional wrinkle is that the object is being set by an arbitrary thread
context at dispatch level. Although that can be changed.

Normally I would xcreate a serialization sem and protect it with a spin
lock. If pended I would interlock the IRP and service it with a single
thread.

I friend of mine came over from Solaris and felt this would work. I
couldn't answer him with 100% certainty.



"Pavel A." wrote:

Well, supose you have some threads waiting on a autoreset/syncronisation
object.
You set the object, 1 thread is waked.

So far everything is SMP safe, but, if you set the object again (even at

So, for this system to be usable for syncronisation, you will need to
protect the evet somehow, so, only after the waked thread finished you can
set the object again.

So, you are reinventing the weel only to get another spinlock/mutex.

KeWaitForSingleObject is perfectly SMP safe, but if you try to use the wrong
syncronization object then you have a problem. The scenario being described
is perfect for a mutex (or if you want a counting semaphore that you
contrain by your programming to never pass 1). You don't want to use a
spinlock, because:

1. You are impacting scheduling of other threads, where this is not
needed.
2. The thread you are protecting is then running at DISPATCH_LEVEL and
cannot perform many operations!

Using spinlocks when they are not needed, is just as bad and stupid as not
using snychronization when it is needed.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply



"Gabriel Bogdan" <na@na.na> wrote in message
news:%23yjXp%23rFFHA.2180@TK2MSFTNGP12.phx.gbl...

This was the statement I was looking for "...perfectly SMP safe..."
However, in order to be SMP safe, it must internally use a spinlock. (Lock
prefixed xchg generally are not relied on by MS for SMP safety.) Don, would
you know why KeWaitForSingleObject() is perfectly SMP safe? By the sound of
your title you seem to work for MS, so you could possibly check the source
real quick and let us know whether it is internally using a spin lock or bus
locked exchange.


"Don Burn" wrote:

I don't work for Microsoft, over the years I have seen the sources. Yes
they do use a spin lock, if you are doing something quick that is the right
thing to do, but if you are doing something that takes anytime, this is a
bad idea. Spinlock should only be used to protect short term operations,
there are many cases where drivers use spin locks, instead of choosing an
appropriate locking model for longer operations.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply



"webman" <webman@discussions.microsoft.com> wrote in message
news:3D3F4F7D-AAE8-4C83-875C-C59E331DAA69@microsoft.com...

The function itself is SMP safe.
How you use it might be or might be not safe.

I'm quite sure that the vast majority of the system functions are SMP safe
and the exceptions are clearly labeled.

And, while on uniprocesors spinlocks represent a simple raise to DISPATC on
a SMP system they do use the proper interlocked semantics, like "lock xchg"
or whatever it's appropriate for the platform.

Yes it is safe.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"webman" <webman@discussions.microsoft.com> wrote in message
news:332AD265-EAD1-4437-934A-D3FD3DB91C81@microsoft.com...

Yes it uses a spinlock internally, the very spinlock which guards the
by-priority thread database. It is called KiDispatcherLock, and it is a highly
optimized queued spinlock in modern Windows.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com