Hi. Sorry if this is an obvious question to some: If I’m inside a spinlock
as a result of an app call or a cleanup/removal operation, can I be sure
that a callback function won’t run? Oney says that inside a spinlock you’re
at DISPATCH_LEVEL and nothing at this or lower level can run. But a callback
can be triggered by an interrupt in a lower level driver at a much higher
level that then calls back at DISPATCH_LEVEL. Is this guaranteed not to
happen if I’m already inside a spinlock? You can see I want to spinlock the
same resource in the callback function but this will hang forever if it can
happen when already in one. It would only be safe if the underlying event is
guaranteed to queue the event until I release the spinlock and it drops back
to PASSIVE_LEVEL. I’m dealing here with the 1394 lower level drivers.
Thanks, Mike
You are guaranteed that the dpc routine is not going to run on the same cpu
that your spinlock protected code is running on. However there is no
guarantee at all that the dpc routine is not going to run on another cpu.
=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
Sent: Friday, October 20, 2006 7:01 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] spinlock clarificationHi. Sorry if this is an obvious question to some: If I’m
inside a spinlock as a result of an app call or a
cleanup/removal operation, can I be sure that a callback
function won’t run? Oney says that inside a spinlock you’re
at DISPATCH_LEVEL and nothing at this or lower level can run.
But a callback can be triggered by an interrupt in a lower
level driver at a much higher level that then calls back at
DISPATCH_LEVEL. Is this guaranteed not to happen if I’m
already inside a spinlock? You can see I want to spinlock the
same resource in the callback function but this will hang
forever if it can happen when already in one. It would only
be safe if the underlying event is guaranteed to queue the
event until I release the spinlock and it drops back to
PASSIVE_LEVEL. I’m dealing here with the 1394 lower level drivers.
Thanks, Mike
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256To unsubscribe, visit the List Server section of OSR Online
at http://www.osronline.com/page.cfm?name=ListServer
Thanks, Mark - that’s why I prefer the spinlock of course but I was worried
about the same CPU case and a possible deadlock (handshaking flags seems
more hassle)… Mike
----- Original Message -----
From: Mark Roddy
To: Windows System Software Devs Interest List
Sent: Friday, October 20, 2006 12:50 PM
Subject: RE: [ntdev] spinlock clarification
You are guaranteed that the dpc routine is not going to run on the same cpu
that your spinlock protected code is running on. However there is no
guarantee at all that the dpc routine is not going to run on another cpu.
=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
Sent: Friday, October 20, 2006 7:01 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] spinlock clarificationHi. Sorry if this is an obvious question to some: If I’m
inside a spinlock as a result of an app call or a
cleanup/removal operation, can I be sure that a callback
function won’t run? Oney says that inside a spinlock you’re
at DISPATCH_LEVEL and nothing at this or lower level can run.
But a callback can be triggered by an interrupt in a lower
level driver at a much higher level that then calls back at
DISPATCH_LEVEL. Is this guaranteed not to happen if I’m
already inside a spinlock? You can see I want to spinlock the
same resource in the callback function but this will hang
forever if it can happen when already in one. It would only
be safe if the underlying event is guaranteed to queue the
event until I release the spinlock and it drops back to
PASSIVE_LEVEL. I’m dealing here with the 1394 lower level drivers.
Thanks, Mike
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256To unsubscribe, visit the List Server section of OSR Online
at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Hi Mark: One other question - your reply implies that all “real time”
callbacks from lower level driver are in fact DPCs. I wasn’t aware of that
(I’ve not seen it documented). Is this a fully safe assumption with the 1394
system drivers (ohci1394.sys and USB1384.sys)? Thanks for the
clarification… Mike
----- Original Message -----
From: Mark Roddy
To: Windows System Software Devs Interest List
Sent: Friday, October 20, 2006 12:50 PM
Subject: RE: [ntdev] spinlock clarification
You are guaranteed that the dpc routine is not going to run on the same cpu
that your spinlock protected code is running on. However there is no
guarantee at all that the dpc routine is not going to run on another cpu.
=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
Sent: Friday, October 20, 2006 7:01 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] spinlock clarificationHi. Sorry if this is an obvious question to some: If I’m
inside a spinlock as a result of an app call or a
cleanup/removal operation, can I be sure that a callback
function won’t run? Oney says that inside a spinlock you’re
at DISPATCH_LEVEL and nothing at this or lower level can run.
But a callback can be triggered by an interrupt in a lower
level driver at a much higher level that then calls back at
DISPATCH_LEVEL. Is this guaranteed not to happen if I’m
already inside a spinlock? You can see I want to spinlock the
same resource in the callback function but this will hang
forever if it can happen when already in one. It would only
be safe if the underlying event is guaranteed to queue the
event until I release the spinlock and it drops back to
PASSIVE_LEVEL. I’m dealing here with the 1394 lower level drivers.
Thanks, Mike
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256To unsubscribe, visit the List Server section of OSR Online
at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
sorry, that should have read 1394BUS.sys - my fingers type USB
automatically! Mike
----- Original Message -----
From: Mike Kemp
To: Windows System Software Devs Interest List
Sent: Friday, October 20, 2006 2:01 PM
Subject: Re: [ntdev] spinlock clarification
Hi Mark: One other question - your reply implies that all “real time”
callbacks from lower level driver are in fact DPCs. I wasn’t aware of that
(I’ve not seen it documented). Is this a fully safe assumption with the 1394
system drivers (ohci1394.sys and USB1384.sys)? Thanks for the
clarification… Mike
----- Original Message -----
From: Mark Roddy
To: Windows System Software Devs Interest List
Sent: Friday, October 20, 2006 12:50 PM
Subject: RE: [ntdev] spinlock clarification
You are guaranteed that the dpc routine is not going to run on the same cpu
that your spinlock protected code is running on. However there is no
guarantee at all that the dpc routine is not going to run on another cpu.
=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
Sent: Friday, October 20, 2006 7:01 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] spinlock clarificationHi. Sorry if this is an obvious question to some: If I’m
inside a spinlock as a result of an app call or a
cleanup/removal operation, can I be sure that a callback
function won’t run? Oney says that inside a spinlock you’re
at DISPATCH_LEVEL and nothing at this or lower level can run.
But a callback can be triggered by an interrupt in a lower
level driver at a much higher level that then calls back at
DISPATCH_LEVEL. Is this guaranteed not to happen if I’m
already inside a spinlock? You can see I want to spinlock the
same resource in the callback function but this will hang
forever if it can happen when already in one. It would only
be safe if the underlying event is guaranteed to queue the
event until I release the spinlock and it drops back to
PASSIVE_LEVEL. I’m dealing here with the 1394 lower level drivers.
Thanks, Mike
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256To unsubscribe, visit the List Server section of OSR Online
at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
I don’t know what exactly you mean by ‘real time callbacks’, but I was
referring specifically to DPC routines, either as a consequence of isr dpc
queuing or timer events. If the callback is documented as running at
DISPATCH_LEVEL then it is not going to magically interrupt a spinlock code
segment that is also running at DISPATCH_LEVEL but it may run concurrently
on another CPU.
=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
Sent: Friday, October 20, 2006 9:01 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] spinlock clarificationHi Mark: One other question - your reply implies that all “real time”
callbacks from lower level driver are in fact DPCs. I wasn’t
aware of that (I’ve not seen it documented). Is this a fully
safe assumption with the 1394 system drivers (ohci1394.sys
and USB1384.sys)? Thanks for the clarification… Mike----- Original Message -----
From: Mark Roddy
To: Windows System Software Devs Interest List
Sent: Friday, October 20, 2006 12:50 PM
Subject: RE: [ntdev] spinlock clarificationYou are guaranteed that the dpc routine is not going to run
on the same cpu
that your spinlock protected code is running on. However there is no
guarantee at all that the dpc routine is not going to run on
another cpu.=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
> Sent: Friday, October 20, 2006 7:01 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] spinlock clarification
>
> Hi. Sorry if this is an obvious question to some: If I’m
> inside a spinlock as a result of an app call or a
> cleanup/removal operation, can I be sure that a callback
> function won’t run? Oney says that inside a spinlock you’re
> at DISPATCH_LEVEL and nothing at this or lower level can run.
> But a callback can be triggered by an interrupt in a lower
> level driver at a much higher level that then calls back at
> DISPATCH_LEVEL. Is this guaranteed not to happen if I’m
> already inside a spinlock? You can see I want to spinlock the
> same resource in the callback function but this will hang
> forever if it can happen when already in one. It would only
> be safe if the underlying event is guaranteed to queue the
> event until I release the spinlock and it drops back to
> PASSIVE_LEVEL. I’m dealing here with the 1394 lower level drivers.
> Thanks, Mike
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online
> at http://www.osronline.com/page.cfm?name=ListServer
>
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256To unsubscribe, visit the List Server section of OSR Online
at http://www.osronline.com/page.cfm?name=ListServer
By “real time callbacks” I mean callbacks that are installed into the 1394
isochronous handler to call me when specific buffers have been sent /
received. These are real time in the sense that when the buffer has actually
been transmitted/received there will be a low level event - I’m assuming an
interrupt (the 1394 bus drivers are black box) - anyway I know that during
my spinlock the event may happen at a much higher priority that demands to
call my callback. The callback is documented as happening at DISPATCH_LEVEL.
The assurance I needed was that on the real time event, control would not
transfer to my callback on the same CPU if I am within any spinlock (i.e. at
dispatch_level already).
(Actually I don’t think that would be magic, it seems a reasonable scenario
that might be the more efficient way of handling real time service, anyway
it an OS design decision that I’ve not been clear about).
I’m beginning to realise that the lower level driver must accomplish this by
queuing a DPC when such a callback is required. This I’m assuming will be
executed (if a single CPU) as soon as I release a spinlock that lets the
thread drop back to PASSIVE_LEVEL, or (multi CPU) immediately on any CPU
that is already at PASSIVE_LEVEL. Therefore grabbing the same spinlock in
the callback cannot deadlock, but will spin if its a different CPU.
I’m just trying to clarify my growing understanding of how the underlying
drivers *must* work. I can’t find any documentation that confirms this to
the level of certainty that I like as a programmer! Naturally I’d prefer it
if there were a published description of the operation of 1394BUS.sys and
ohci1394.sys bus drivers, but failing that, experiment and knowledge sharing
have to suffice.
So thanks for the clarification.
Best regard, Mike.
----- Original Message -----
From: Mark Roddy
To: Windows System Software Devs Interest List
Sent: Friday, October 20, 2006 10:47 PM
Subject: RE: [ntdev] spinlock clarification
I don’t know what exactly you mean by ‘real time callbacks’, but I was
referring specifically to DPC routines, either as a consequence of isr dpc
queuing or timer events. If the callback is documented as running at
DISPATCH_LEVEL then it is not going to magically interrupt a spinlock code
segment that is also running at DISPATCH_LEVEL but it may run concurrently
on another CPU.
=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
Sent: Friday, October 20, 2006 9:01 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] spinlock clarificationHi Mark: One other question - your reply implies that all “real time”
callbacks from lower level driver are in fact DPCs. I wasn’t
aware of that (I’ve not seen it documented). Is this a fully
safe assumption with the 1394 system drivers (ohci1394.sys
and USB1384.sys)? Thanks for the clarification… Mike----- Original Message -----
From: Mark Roddy
To: Windows System Software Devs Interest List
Sent: Friday, October 20, 2006 12:50 PM
Subject: RE: [ntdev] spinlock clarificationYou are guaranteed that the dpc routine is not going to run
on the same cpu
that your spinlock protected code is running on. However there is no
guarantee at all that the dpc routine is not going to run on
another cpu.=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
> Sent: Friday, October 20, 2006 7:01 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] spinlock clarification
>
> Hi. Sorry if this is an obvious question to some: If I’m
> inside a spinlock as a result of an app call or a
> cleanup/removal operation, can I be sure that a callback
> function won’t run? Oney says that inside a spinlock you’re
> at DISPATCH_LEVEL and nothing at this or lower level can run.
> But a callback can be triggered by an interrupt in a lower
> level driver at a much higher level that then calls back at
> DISPATCH_LEVEL. Is this guaranteed not to happen if I’m
> already inside a spinlock? You can see I want to spinlock the
> same resource in the callback function but this will hang
> forever if it can happen when already in one. It would only
> be safe if the underlying event is guaranteed to queue the
> event until I release the spinlock and it drops back to
> PASSIVE_LEVEL. I’m dealing here with the 1394 lower level drivers.
> Thanks, Mike
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online
> at http://www.osronline.com/page.cfm?name=ListServer
>
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256To unsubscribe, visit the List Server section of OSR Online
at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer