Hi All,
How do I synch. 2 displatch level threads in Kernel one running as DPC and
other running as kernel thread at priority 25. I am having problem using
KeWaitForSingleObject as the timeout is 0 for dispatch level. I don't want to
use spin lock at it hampers performance by keeping the cpu busy.
Also is there a mechanism for me to crash or halt the system when ever stack
size reaches the maximum size of 8K and not continue the processing futhur.
As it will help me isolate the problem rather than corrupting the stack and
making it difficult to debug.
Shankar

Well 25 is one of the device IRQL so the only way to synchronize is the
interrupt spin lock. You should not be taking a long time at that IRQL so
don't worry about the other CPU's spinning. If you do take a lot of time in
the ISR, you either have a device for a custom situation, so you should not
care, or else your design is wrong.

For the stack question check out IoGetRemainingStackSize.


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



"Shankar" <Shankar Agarwal@community.nospam> wrote in message
news:32FCEECE-5D65-4B08-BD02-975E51B84A59@microsoft.com...

Hi Don,
Thanks a lot for your response. I want my thread running at 25 to wait for
the DPC scheduled from an ISR to finish. ALso it is a uniprocessor machine.
Right now it looks like the DPC executes at lower priority than my thread as
a result I am having some problem. Is there a way to make the thread running
at 25 with IRQL at dispatch level to wait and wakt it up from the DPC also
running at dispatch level. I tried to see the documentation for raising the
priority for DPC but the api KeSetImportanceDpc does not seem to be present
in my OS which is Windows XP embedded. Also I am not 100% sure if that will
help. Can you please suggest something.
Shankar

"Don Burn" wrote:

You cannot do this, the processor will always run the highest IRQL
operation. You need to redesign your model. First you say a thread running
at IRQL 25, are you doing this with KeRaiseIrql? If so this is a bad idea,
the only thing that should run at that level is your ISR and the code that
holds the interrupt spin lock.

What you should be doing is:

1. In the ISR grab all the state you need from the device and disable
interrupts
2. Queue your DpcForIsr
3. In the DpcForIsr perform the actions you want
4. Acquire the Interrupt spin lock (use KeSynchronizeExecution if you
support older OS'es)
5. Do the actions you would have waited on before doing, then enable the
interrupts for the device.
6. Release the interrupt spin lock and exit the DpcForIsr


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



"Shankar" <Shankar Agarwal@community.nospam> wrote in message
news:917FBE17-E73A-426C-906F-54864EBB5D59@microsoft.com...

Hi Don,
I am not running at IRQL 25 but at priority 25. I used the following command
to do that // raise this thread's priority (0=min, 15=user max, 31=kernel max)
KeSetPriorityThread(KeGetCurrentThread(), 25);
Shankar

"Don Burn" wrote:

Your scenario is not clear to me. You have two threads of execution:

T1 is running at priority 25 and at what IRQL?
The other execution is the result of an ISR queueing a DPC right?
You want to wait in T1 for the DPC completion?

If i got it correct, T1 is running at DISPATCH_LEVEL but KeSetPriorityThread
can only be called at PASSIVE_LEVEL so how come T1 is running at
DISPATCH_LEVEL? Also at DISPATCH_LEVEL, the windows scheduler is out of
picture so there is no scheduling.

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


"Shankar" <Shankar Agarwal@community.nospam> wrote in message
news:EF6BEA3C-457C-456A-960E-55BE68BD0D19@microsoft.com...

Shankar,

You have a bigger problem, DPC's run when the processor is
transitioning out of DISPATCH_LEVEL. So your DPC will never run if you keep
thr thread at DISPATCH_LEVEL. Make your thread with priority 25 a
PASSIVE_LEVEL thread, then you can wait, and the DPC will run.


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



"Shankar" <Shankar Agarwal@community.nospam> wrote in message
news:EF6BEA3C-457C-456A-960E-55BE68BD0D19@microsoft.com...

He is running at _proority_ 25, not IRQL. He is running at DISPATCH_LEVEL.

"Don Burn" <burn@stopspam.acm.org> wrote in message
news:uGDvh6%23NGHA.2176@TK2MSFTNGP10.phx.gbl...

Please use spinlocks, they are OK if the code is not holding it for a long
time. Sorry, they are the only sync object available on DISPATCH_LEVEL.

Another way is to redesign the code to be async, relying on event callbacks
instead of blocked waiting. This usually means - separating the logic to lots
of tiny functions.

IoGetRemainingStackSize

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

You cannot. Lower the IRQL to PASSIVE_LEVEL, and wait there.

DPCs are sometimes delayed till the next timer tick. But High importance DPCs
are never delayed this way, and preempt any thread. Use KeSetImportanceDpc and
set it to High if you need this.

No ways. Lower the IRQL to something below 25 (by releasing the interrupt
spinlock or moving the wait outside the KeSynchronizeExecutionCallback) and
wait there.

Why? I think they have the same kernel binary as usual XP.

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

Then you're on IRQL 0, and can wait.

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

Hi All,
Thanks a lot for your help. I figured out the problem. It was a stupid
mistake on my part which was making the thread T1 which is running at priorty
25 to execute between a small windown where the call to hard ware is made and
it completes the task and ISR is invoked. But the whole concept of
DISPATH_LEVEL and PASSIVE_LEVEL that you guys helped clarify was good and
helped me narrow down the problem.
Regards,
Shankar

"Maxim S. Shatskih" wrote: