WorkItem

Hi,
Please tell me how to create WorkItem in kmdf type as CriticalWorkQueue.
Please reply.

sree

You can’t queue a work item with a priority CriticalWorkQueue. The docs clearly state this

QueueType
Specifies a WORK_QUEUE_TYPE value that stipulates the type of system worker thread to handle the work item. Drivers must specify DelayedWorkQueue.

Why do you think you need to use CriticalWorkQueue?

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@nestgroup.net
Sent: Tuesday, September 23, 2008 10:08 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] WorkItem

Hi,
Please tell me how to create WorkItem in kmdf type as CriticalWorkQueue.
Please reply.

sree


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

I read the msdn about IoQueueWorkItem. But i have to port a driver with CriticalWorkQueue. I thought this was a mistake done by the old programmer. I just used the wdf work item with default options. But now iam in a trouble. I explain you the scnenario in WDM and in KMDF

see the code zuedo code

interruptHandler()
{
if(interrupt == XErr1)
{
DpcQ(DpcForXErr1)
}


}

DpcForXErr1()
{


IoQueueWorkItem(pWorkItemBoardReset, WorkItemRoutine,
CriticalWorkQueue, pInfo);
}
WorkItemRoutine()
{
Reset();



KeSetEvent(XErrIntrEvent);
}

WaitInterrupt()
{
KeWaitForSingleObject(XErrIntrEvent,timeout,…);
{
do
}
}

Let XErr1 interrupt comes.I tell you the sequence of operation

In WDM
DpcForXErr1() > WorkItemRoutine > Reset > WaitInterrupt

In KMDF
DpcForXErr1() > #### wait timeouts ### > … WorkItemRoutine > Reset…

In WDM work item is executing in dpc level but in wdf it is executing passive level…
I read about AutomaticSerialization of work item config.will this do the same for me?

sorry for the lenghty details…

sree

Why do you think you need to use CriticalWorkQueue?

d

The only way your workitem executes at DPC_LEVEL is if *you* raised IRQL,
either explicitly or by acquiring a spinlock and holding it.

So, something in the

matters greatly to this analysis.

Keep something in mind - You do not control what (system) thread will
execute your work-item. Waiting in a work-item for another work-item to
set an event is a ‘really bad idea’ (translation, potential deadlock).

Now it is perfectly reasonable for some *other* entity to have deferred the
IRP processing which dispatches into your routine that eventually calls
WaitForInterrupt() onto a workitem.

Two things:

  1. If you need to have guarantees about the thread-context to prevent
    deadlock, then, create your own worker thread and do not use a work-item to
    borrow the systems.

  2. Eliminate the problem by moving the passive level processing. By this I
    mean the following:

  • Observe that your processing is
    a) an ISR that requests a DPC.
    b) a DPC that does some work and then schedules a WorkItem.
    c) a WorkItem that does some work at PASSIVE_LEVEL and then sets an
    event to signal a waiter.
    d) a waiter hanging around (maybe, maybe not) that is interested in
    the results of a,b,c.

So what if the processing done at PASSIVE_LEVEL in the workitem was deferred
to either the workitem or the waiter thread and the DPC set the event and
the processing that you now have in the work-item is simply something that
the ‘first one to enter’ will perform. If the workitem gets there first,
great, it performs the operation and exits. If the waiter gets there first,
it performs the operation and continues. If the workitem happens to show up
after a waiter has already performed the operation, well, the workitem can
just do nothing.

No deadlock because none of the actors in this case will need to wait for
the ‘task’ at passive level to be started. Of course the waiters must wait
for the task to be completed but once it is started it will complete (unless
you have other deadlock issues).

Workitem usage can be very tricky given that concurrent execution of
workitems is not necessarily guaranteed (but may happen). The system has a
limited number of threads to service workitems. Waiting in a workitem
*blocks* that thread for the duration of the wait and prevents other queued
workitems from being dispatched on *that* thread.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@nestgroup.net
Sent: Wednesday, September 24, 2008 11:32 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] WorkItem

I read the msdn about IoQueueWorkItem. But i have to port a driver with
CriticalWorkQueue. I thought this was a mistake done by the old programmer.
I just used the wdf work item with default options. But now iam in a
trouble. I explain you the scnenario in WDM and in KMDF

see the code zuedo code

interruptHandler()
{
if(interrupt == XErr1)
{
DpcQ(DpcForXErr1)
}


}

DpcForXErr1()
{


IoQueueWorkItem(pWorkItemBoardReset, WorkItemRoutine,
CriticalWorkQueue, pInfo);
}
WorkItemRoutine()
{
Reset();



KeSetEvent(XErrIntrEvent);
}

WaitInterrupt()
{
KeWaitForSingleObject(XErrIntrEvent,timeout,…);
{
do
}
}

Let XErr1 interrupt comes.I tell you the sequence of operation

In WDM
DpcForXErr1() > WorkItemRoutine > Reset > WaitInterrupt

In KMDF
DpcForXErr1() > #### wait timeouts ### > … WorkItemRoutine > Reset…

In WDM work item is executing in dpc level but in wdf it is executing
passive level…
I read about AutomaticSerialization of work item config.will this do the
same for me?

sorry for the lenghty details…

sree

Why do you think you need to use CriticalWorkQueue?

d


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer