Odd behaviour with KeWaitForMutexObject().

NTFSD
1

I’m using a mutex to protect functions which access a linked list
(i.e. add, remove, find, etc). Since I may access these functions at
DISPATCH_LEVEL, I have no choice but to use a timeout value of zero. I
use the following mechanism:

while (KeWaitForMutexObject(&myMutex, Executive, KernelMode, FALSE, 0)
!= STATUS_SUCCESS);

My understanding is that the above wait call will always immediately
return either STATUS_SUCCESS or STATUS_TIMEOUT, therefore I must use the
while loop to ensure that I only proceed when access has been granted.
Thus the appearance of the above wait mechanism seems to work like a
spin lock (threads will never sleep, just busy wait).

Now the problem is that on rare occasions I will have two functions
grab the mutex at the same time, and I get into a situation where by I
can be searching the list elements after they have been removed. If I
simply change the mechanism to be a spin lock, I never have this
problem.

So my questions are: Am I correctly waiting on this mutex? Should
I be using a spin lock instead since it appears to work like one in any
case?

The reason I don’t want to use the spin lock mechanism is that it
does appear to significantly slow down my driver.

2

Edward,
its almost always better to use a mechanism like Spin Lock since it is
guaranteed to be Multiprocessor safe. Regarding the slowing down of the
system, try and minimize the operations you do while you hold the spin lock.
Also see to it that these operations are not expensive in terms of
consumption of CPU cycles.
The other alternative is to have your own synchronization object implemented
using some standard algorithms like the Lamport Bakery algorithm.

regds
amit
----- Original Message -----
From: Edward Mandac
To: File Systems Developers
Sent: Friday, July 14, 2000 2:07 AM
Subject: [ntfsd] Odd behaviour with KeWaitForMutexObject().

> I’m using a mutex to protect functions which access a linked list
> (i.e. add, remove, find, etc). Since I may access these functions at
> DISPATCH_LEVEL, I have no choice but to use a timeout value of zero. I
> use the following mechanism:
>
> while (KeWaitForMutexObject(&myMutex, Executive, KernelMode, FALSE, 0)
> != STATUS_SUCCESS);
>
> My understanding is that the above wait call will always immediately
> return either STATUS_SUCCESS or STATUS_TIMEOUT, therefore I must use the
> while loop to ensure that I only proceed when access has been granted.
> Thus the appearance of the above wait mechanism seems to work like a
> spin lock (threads will never sleep, just busy wait).
>
> Now the problem is that on rare occasions I will have two functions
> grab the mutex at the same time, and I get into a situation where by I
> can be searching the list elements after they have been removed. If I
> simply change the mechanism to be a spin lock, I never have this
> problem.
>
> So my questions are: Am I correctly waiting on this mutex? Should
> I be using a spin lock instead since it appears to work like one in any
> case?
>
> The reason I don’t want to use the spin lock mechanism is that it
> does appear to significantly slow down my driver.
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@veritas.com
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>

3

> I’m using a mutex to protect functions which access a linked list

(i.e. add, remove, find, etc). Since I may access these functions at
DISPATCH_LEVEL, I have no choice but to use a timeout value of zero. I

Use spinlock in this case, not mutex.

Max