Antwort: RE: Interrupt SpinLock under Win2k - part 2

NTDEV
1

> Is there some overwhelming reason why KeSynchronizeExecution will not
work

for you?
(and the other similar responses)

KeSynchronizeExecution requires me to pack all context into some
structure,
and to spilt my code into 2 functions per function I have now.
Of course it’s possible to do, but it will make the code much harder to
read
and what’s the more important thing - it will take much longer to
implement.
I know it’s a shame, but I need to make the changes (move some stuff from
DPC
to ISR) today, and there are many many functions with different context’
to synchronize with the ISR.
So it’s basically all about development time.

By the way, spinning on the interlocked operation is not a good idea. A
two
phased operation where the spin is on a non-interlocked operation is a
better approach.

If that’s the only problem, that shouldn’t be hard to change.
Like about this?

while(1)
{
while( *((volatile ULONG*) &g_nMyLockVar) != 0 )
/* spin */;
if( InterlockedCompareExchange( &g_nMyLockVar, 1, 0 ) == 0 )
break;
}

Regards,

Paul Groke

2

> KeSynchronizeExecution requires me to pack all context into some

structure,
and to spilt my code into 2 functions per function I have now.

So what?

Of course it’s possible to do, but it will make the code much harder to
read

No. It will divide the code running at DIRQL to separate functions. Very good.

and what’s the more important thing - it will take much longer to
implement.

Just a typing issue, which will not influence the timeline of any system-level
development project :slight_smile: debugging is by far more an issue :slight_smile:

So it’s basically all about development time.

Usually, you cannot do any system-level development in a hurry.

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

3

Hi!

> KeSynchronizeExecution requires me to pack all context into some
> structure,
> and to spilt my code into 2 functions per function I have now.

So what?

> Of course it’s possible to do, but it will make the code much
> harder to read

No. It will divide the code running at DIRQL to separate functions.
Very good.

Thats another way to look at it. I was thinking more about it
breaking the “visual” flow of execution even more. Whatever.
Since nobody told me yet it’s ok to do as I wanted I’m currently
doing it the KeSynchronizeExecution way anyway…

> and what’s the more important thing - it will take much longer to
> implement.

Just a typing issue, which will not influence the timeline of any
system-level development project :slight_smile: debugging is by far more an
issue :slight_smile:

Well, the driver works so far, I just have to move some logic from
a DPC to the ISR. No IRP handling, no calls outside the driver,
just a state-machine that’s already complicated enough for my taste.
So there should be no IRQL issues, and since the code already works,
with just the DPC latency being a problem…
Btw. the maybe 2-3 hours I would have saved using the hack would
have been additional time for testing/debugging…
See what I mean? If I were doing this driver the way I think it
should be done there would be many things different from how they
got because of the very tight schedule…

> So it’s basically all about development time.

Usually, you cannot do any system-level development in a hurry.

I agree. Please come here and tell my boss…

But thanks for the reply anyway :wink:

Regards,

Paul Groke

4

That works well enough. But really you should just go and use
KeSynchronizeExecution, it isn’t that difficult. Also, your emulation does
not interact with the NT ISR mechanism, as does the interrupt spinlock, so
it is incomplete.

=====================
Mark Roddy

-----Original Message-----
From: xxxxx@tab.at [mailto:xxxxx@tab.at]
Sent: Tuesday, June 08, 2004 5:12 AM
To: Windows System Software Devs Interest List
Subject: Antwort: RE: [ntdev] Interrupt SpinLock under Win2k - part 2

Is there some overwhelming reason why KeSynchronizeExecution will not
work
for you?
(and the other similar responses)

KeSynchronizeExecution requires me to pack all context into some structure,
and to spilt my code into 2 functions per function I have now.
Of course it’s possible to do, but it will make the code much harder to read
and what’s the more important thing - it will take much longer to implement.
I know it’s a shame, but I need to make the changes (move some stuff from
DPC to ISR) today, and there are many many functions with different
context’
to synchronize with the ISR.
So it’s basically all about development time.

By the way, spinning on the interlocked operation is not a good idea.
A
two
phased operation where the spin is on a non-interlocked operation is a
better approach.

If that’s the only problem, that shouldn’t be hard to change.
Like about this?

while(1)
{
while( *((volatile ULONG*) &g_nMyLockVar) != 0 )
/* spin */;
if( InterlockedCompareExchange( &g_nMyLockVar, 1, 0 ) == 0 )
break;
}

Regards,

Paul Groke

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

5

Hi Mark!

That works well enough. But really you should just go and use
KeSynchronizeExecution, it isn’t that difficult. Also, your emulation
does not interact with the NT ISR mechanism, as does the interrupt
spinlock, so it is incomplete.

Since I’m already about 1/2 way through I’ll probably stick to the
KeSynchronizeExecution way. But just out of curiosity, what’s missing
when I do

  1. raise IRQL
  2. spin
  3. do stuff
  4. “unspin” :wink:
  5. lower IRQL

I thought the KeRaiseIrql/KeLowerIrql (included in the code-snippet in
my first mail) pair is all that’s neede for the NT ISR mechanism to be
happy. An instead of the original interrupt SpinLock I’d use my own
which should also be sufficient.

Again, I think I’ll not use it anymore, just our of curiosity…

thatnks for your reply,
Regards,

Paul Groke

6

Well you aren’t actually replacing your interrupt spinlock with a new home
grown spinlock, you are adding your new spinlock into the mix. I’m not sure
it matters, as I haven’t time to think through all the consequences, but
your isr is now acquiring two spinlocks, and your dispatch level code is not
preventing your isr from running. Offhand I think it probably doesn’t
matter.

=====================
Mark Roddy

-----Original Message-----
From: xxxxx@tab.at [mailto:xxxxx@tab.at]
Sent: Tuesday, June 08, 2004 9:19 AM
To: Windows System Software Devs Interest List
Subject: RE: Antwort: RE: [ntdev] Interrupt SpinLock under Win2k - part 2

Hi Mark!

That works well enough. But really you should just go and use
KeSynchronizeExecution, it isn’t that difficult. Also, your emulation
does not interact with the NT ISR mechanism, as does the interrupt
spinlock, so it is incomplete.

Since I’m already about 1/2 way through I’ll probably stick to the
KeSynchronizeExecution way. But just out of curiosity, what’s missing when I
do

  1. raise IRQL
  2. spin
  3. do stuff
  4. “unspin” :wink:
  5. lower IRQL

I thought the KeRaiseIrql/KeLowerIrql (included in the code-snippet in my
first mail) pair is all that’s neede for the NT ISR mechanism to be happy.
An instead of the original interrupt SpinLock I’d use my own which should
also be sufficient.

Again, I think I’ll not use it anymore, just our of curiosity…

thatnks for your reply,
Regards,

Paul Groke

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

7

There’s also the problem that the interrupt lock is not ment to be
accessed with the regular spinlock routines, and thus the implementation
could be changed down the line. Nothing’s better than swapping 1 and 0
into something that turns out to be the head of a queue of waiters and
crashing the system.

It’s great that we all “know” how spinlocks are implemented. That
doesn’t mean we can assume they’ll always be implemented that way. If
you assume they will be you’re risking the stability of your customer’s
machines down the line in order to save a few hours of development time.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Tuesday, June 08, 2004 6:31 AM
To: Windows System Software Devs Interest List
Subject: RE: Antwort: RE: [ntdev] Interrupt SpinLock under Win2k - part
2

Well you aren’t actually replacing your interrupt spinlock with a new
home grown spinlock, you are adding your new spinlock into the mix. I’m
not sure it matters, as I haven’t time to think through all the
consequences, but your isr is now acquiring two spinlocks, and your
dispatch level code is not preventing your isr from running. Offhand I
think it probably doesn’t matter.

=====================
Mark Roddy

-----Original Message-----
From: xxxxx@tab.at [mailto:xxxxx@tab.at]
Sent: Tuesday, June 08, 2004 9:19 AM
To: Windows System Software Devs Interest List
Subject: RE: Antwort: RE: [ntdev] Interrupt SpinLock under Win2k - part
2

Hi Mark!

That works well enough. But really you should just go and use
KeSynchronizeExecution, it isn’t that difficult. Also, your emulation
does not interact with the NT ISR mechanism, as does the interrupt
spinlock, so it is incomplete.

Since I’m already about 1/2 way through I’ll probably stick to the
KeSynchronizeExecution way. But just out of curiosity, what’s missing
when I do

  1. raise IRQL
  2. spin
  3. do stuff
  4. “unspin” :wink:
  5. lower IRQL

I thought the KeRaiseIrql/KeLowerIrql (included in the code-snippet in
my first mail) pair is all that’s neede for the NT ISR mechanism to be
happy.
An instead of the original interrupt SpinLock I’d use my own which
should also be sufficient.

Again, I think I’ll not use it anymore, just our of curiosity…

thatnks for your reply,
Regards,

Paul Groke

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com