Hi
I have a general question. A little confusion…
I am trying to understand what Windows does when dispatcher objects are used in Multiprocessor System.
They say: “uses spinlocks on multiprocessor systems”. Why?
I know spin locks raise IRQL value. But irql is associated with a single cpu. Raising IRQL value doesn’t effect other cpus. So raising IRQL can’t be the reason.
Also I know Dispatcher objects are low level irql-synchronization objects.
My question is:
When dispatcher objects are used in kernel or user mode, does windows synchronize protected code between cpus?
If not what makes spin lock different so it can make it happen?
Also if not How can user-mode code make inter processor synchronization without using spin locks?
Thanks…
Spinlocks raise IRQL and set the locks value to taken. When another CPU
tries to acquire the lock, it raises IRQL, but will not get the lock
since the locks value shows someone else has it, so it spins testing the
value until the other CPU releases the lock. The reason to raise the
IRQL is so that another thread cannot be scheduled on the CPU from.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@gmail.com” wrote in message
news:xxxxx@ntdev:
> Hi
>
> I have a general question. A little confusion…
>
> I am trying to understand what Windows does when dispatcher objects are used in Multiprocessor System.
>
> They say: “uses spinlocks on multiprocessor systems”. Why?
>
> I know spin locks raise IRQL value. But irql is associated with a single cpu. Raising IRQL value doesn’t effect other cpus. So raising IRQL can’t be the reason.
>
> Also I know Dispatcher objects are low level irql-synchronization objects.
>
> My question is:
>
> When dispatcher objects are used in kernel or user mode, does windows synchronize protected code between cpus?
> If not what makes spin lock different so it can make it happen?
>
> Also if not How can user-mode code make inter processor synchronization without using spin locks?
>
> Thanks…
I don’t know who “they” are but “they” SHOULDN’T be saying this. They should be saying:
“Use spinlocks on multiprocessor systems, when protecting shared data that is referenced by ANY code that could be running at IRQLs >= DISPATCH_LEVEL”
If you need to serialize access to shared data, and all the accesses to that data will be at IRQL < DISPATCH_LEVEL, you should most likely use a Dispatcher Object such as a Mutex.
Hmmmm… this question seems a bit confused.
You have some shared data… let’s say its a block of statistics. You need to synchronize access to that data. Let’s say you can guarantee that all references to that data will be at IRQL PASSIVE_LEVEL (you guarantee this by the way you implement your code). The most common choice of serialization primitive here would be one of the Mutex variants.
So, you create a Mutex: You create a variable of type KMUTEX and name it “MyMutex” and you initialize it by calling KeInitializeMutex(&MyMutex, 0);
Now, you make a rule that any code (regardless of where it’s running in the system) that wants to reference (or, perhaps, update) the shared data this Mutex protects must acquire the Mutex before it does so.
So, your code always calls KeWaitForSingleObject or KeWaitForMutexObject (either one, if you’re using a KMUTEX) before it attempts to refer to the shared data. If the Mutex is available, it’s granted. If not, the thread is placed in a non-runnable wait state. “Non-Runnable” is the key here… the thread isn’t eligible for scheduling… on ANY processor.
Simple, right?
Spin locks work the way Don described, which you see is fundamentally different.
Peter
OSR
“Also I know Dispatcher objects are low level irql-synchronization objects.”
This is not true. They are not “low level”, and they are not irql-synchronization.
Spinlocks are “low level”, but they are not irql-synchronization, either. They can change irql, but only to level the playing field.
OP, this article might help you: http://www.osronline.com/article.cfm?id=86
Written in 1997, but still fundamentally sound.
Peter
OSR
Wow, great explanations,
Understood them all.
Thanks
Just wait until you get the bill 
Peter
OSR
xxxxx@osr.com wrote:
Just wait until you get the bill
Peter
OSR
Now, wait a minute. I thought commercial messages were prohibited on
this list…
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> I don’t know who “they” are but “they” SHOULDN’T be saying this. They should be saying:
“Use spinlocks on multiprocessor systems, when protecting shared data that is referenced by ANY code
that could be running at IRQLs >= DISPATCH_LEVEL”
If you need to serialize access to shared data, and all the accesses to that data will
be at IRQL < DISPATCH_LEVEL, you should most likely use a Dispatcher Object such as a Mutex.
It really depends on the situation, namely, on how long you may keep this lock. If your critical section is just a few lines of code and is in high demand use of dispatcher object like mutex may give a significant overhead. Therefore, you may want to use spinlock in this situation. However, spinlock is VERY bad solution if you intent to keep it for more or less significant period of time…
Anton Bassov