< Do you know how the queued spinlock works? It maintains
< a linked list of
< KLOCK_QUEUE_HANDLEs, where the list tail is the
< acquisitor who runs, others are
< acquisitors who wait.

< KLOCK_QUEUE_HANDLE is like Irql variable for usual
< spinlocks.

< You must have at least 1 KLOCK_QUEUE_HANDLE per CPU,
< and use
< KeGetCurrentProcessorNumber to access the correct one,
< with raising on
< DISPATCH_LEVEL beforehand.

I don't understand how queuedspinlocks works anymore. I
thought that there
was only one queue and all cpus were locking themselve
with that queue ex:

KLOCK_QUEUE_HANDLE
|
----------------
| Acquire lock | <----- cpu #0
----------------
----------------
| Acquire lock | <----- cpu #2
----------------
----------------
| Acquire lock | <----- cpu #1
----------------
----------------
| Acquire lock | <----- cpu #3
----------------

If this is not the case but every cpu must have his
KLOCK_QUEUE_HANDLE how
can cpu #2 knows that it must wait because cpu 0 have the
lock if this
lock was putted into the KLOCK_QUEUE_HANDLE of cpu #0 ?

Can someone at Microsoft can explain to me how queued
spinlock really works ?

Thanks

"Daniel Simard" <Daniel-Olivier.Simard@matrox.com> wrote in message
news:1c5401c38681$fc9d8270$a401280a@phx.gbl...
[snip]
Do a web search for MCS locks. They work just the same way.
The lock itself is really a head of a chain of waiters and the lock
owner.
I can explain in more detail if you want but you can probably find
a load of stuff on MCS.
This posting is provided "AS IS" with no warranties, and confers no rights.

Everybody tells me that is works the same that regular
spinlock, but I see real strange things:

Here is my lock code where m_asLockQueue is defined as
(KLOCK_QUEUE_HANDLE m_asLockQueue[20]:

Lock()
{
DbgPrint("CPU %d Before Lock\n", uCurrentCpu);

KeAcquireInStackQueuedSpinLock(&m_oSpinLock,
&m_asLockQueue[uCurrentCpu]);
DbgPrint("CPU %d After Lock\n", uCurrentCpu);
}

Unlock()
{
uCurrentCpu = KeGetCurrentProcessorNumber();
DbgPrint("CPU %d Before UnLock\n", uCurrentCpu);

KeReleaseInStackQueuedSpinLock(&m_asLockQueue
[uCurrentCpu]);
DbgPrint("CPU %d After UnLock\n", uCurrentCpu);
}


Here is my strange traces:

CPU 0 Before Lock
CPU 0 After Lock
CPU 0 Before Lock
CPU 0 After Lock
CPU 0 Before UnLock
CPU 0 After UnLock
CPU 0 Before UnLock
CPU 0 After UnLock

Why the second Lock call doesn't block on cpu 0 since I
have not unlock the first one ?

"Daniel Simard" <Daniel-Olivier.Simard@matrox.com> wrote in message
news:049f01c386b1$25b41c80$a401280a@phx.gbl...
Remember when you output comes out is subject to race conditions.
You have some prints inside the lock and they are serialized only
with others under the lock.
You code doesn't make sense. Keep the LockHandle stuff as stack local
structures. You must use the same guy you used for locking as you used
for unlock. You probably have all sorts of race conditions in your stuff
if you get rescheduled after you get the cpu number.


--
This posting is provided "AS IS" with no warranties, and confers no rights.

On Mon, 29 Sep 2003 11:43:48 -0700, "Neill Clift [MSFT]"
<neillc@microsoft.com> wrote:

Maybe I'm missing something here, but if CPU 0 is always doing the
acquisition, then perhaps there is no guarantee with QSL that the
cpu-recursive acquisition will block. If this is a UP system, the only
'locking' is by IRQL, and his test is invalid.




=====================
Mark Roddy
Windows XP/2000/NT Consulting, Microsoft DDK MVP
Hollis Technology Solutions 603-321-1032
www.hollistech.com
markr@hollistech.com
For Windows Device Driver Training: see www.azius.com

No. You must have a KLOCK_QUEUE_HANDLE per acquisitor.

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