In my 1394 driver I need to detach and attach buffers
when I get a callback from a lower level driver.
Since I need to wait for the detach to complete, before
I attach I want to use KeWaitForSingleObject, which
is signalled from the detach completion routine.
Alas, this is not allowed, since the callback is called
at dispatch level.
What are my options?
Udo Lenz, CCD Videometrie
Well, this is what spinlocks are for - the very purpose on a spinlock is to allow synchronization with the code that may be running at elevated IRQL. Before you attach or detach a buffer, acquire a spinlock, and release it when operation is over…
Anton Bassov
Is there a way to return pending from the lower level driver’s callback into you? Otherwise if that callback is invoked at dispatch, there is nothing you can do to make the detach synchronous. Your best shot is to process everything async and do your work in the detach routine instead of the callback routine
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@compuserve.com
Sent: Friday, April 18, 2008 4:39 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] 1394 IRQL troubles
In my 1394 driver I need to detach and attach buffers
when I get a callback from a lower level driver.
Since I need to wait for the detach to complete, before
I attach I want to use KeWaitForSingleObject, which
is signalled from the detach completion routine.
Alas, this is not allowed, since the callback is called
at dispatch level.
What are my options?
Udo Lenz, CCD Videometrie
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
On Fri, 18 Apr 2008 08:31:24 -0400 (EDT), xxxxx@hotmail.com
wrote:
Well, this is what spinlocks are for - the very purpose on a spinlock is to allow synchronization with the code that may be running at elevated IRQL. Before you attach or detach a buffer, acquire a spinlock, and release it when operation is over…
Anton Bassov
Ok, so I acquire a spinlock, start my detach and acquire the spinlock
again, so it will block until I release the spinlock in my completion
routine. Effectively this works like a wait for an event.
What is the point of the system not allowing me an event driven wait
at dispatch level, but doing the same with spinlocks is ok?
Udo Lenz, CCD Videometrie
On Fri, 18 Apr 2008 07:47:00 -0700, Doron Holan
wrote:
>Is there a way to return pending from the lower level driver’s callback int=
>o you? Otherwise if that callback is invoked at dispatch, there is nothing=
> you can do to make the detach synchronous. Your best shot is to process e=
>verything async and do your work in the detach routine instead of the callb=
>ack routine
Since the completion routines also run at dispatch level and I have
several calls to the lower level driver, that means I need to write a
cascade of completion routines, one for every call to the lower level
driver. Awkward.
Udo Lenz, CCD Videometrie
Awkward maybe, but sometimes that is life. You have to implement your solution in the constraints given. If the constraints create a bad design, that sucks and I am sorry about that, but that is life sometimes…
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@compuserve.com
Sent: Tuesday, April 22, 2008 3:13 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] 1394 IRQL troubles
On Fri, 18 Apr 2008 07:47:00 -0700, Doron Holan
wrote:
>Is there a way to return pending from the lower level driver’s callback int=
>o you? Otherwise if that callback is invoked at dispatch, there is nothing=
> you can do to make the detach synchronous. Your best shot is to process e=
>verything async and do your work in the detach routine instead of the callb=
>ack routine
Since the completion routines also run at dispatch level and I have
several calls to the lower level driver, that means I need to write a
cascade of completion routines, one for every call to the lower level
driver. Awkward.
Udo Lenz, CCD Videometrie
—
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 would not hold onto a spinlock across contexts, this has a high potential for an abandoned lock or a deadlock.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@compuserve.com
Sent: Tuesday, April 22, 2008 3:13 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] 1394 IRQL troubles
On Fri, 18 Apr 2008 08:31:24 -0400 (EDT), xxxxx@hotmail.com
wrote:
Well, this is what spinlocks are for - the very purpose on a spinlock is to allow synchronization with the code that may be running at elevated IRQL. Before you attach or detach a buffer, acquire a spinlock, and release it when operation is over…
Anton Bassov
Ok, so I acquire a spinlock, start my detach and acquire the spinlock
again, so it will block until I release the spinlock in my completion
routine. Effectively this works like a wait for an event.
What is the point of the system not allowing me an event driven wait
at dispatch level, but doing the same with spinlocks is ok?
Udo Lenz, CCD Videometrie
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