I’ve often wondered why synchronization events aren’t commonly used in
place of spinlocks when all resource access is known to occur at IRQL <=
DISPATCH_LEVEL and no timeout on the wait is necessary. As long as the
event can be initialized at PASSIVE_LEVEL, the DDK says that it’s legal
to wait on and signal the event at IRQL <= DISPATCH_LEVEL. Am I missing
something here? This seems like a very good alternative to using
spinlocks for many scenarios. Especially if you want to avoid the
effect of KeAcquireSpinLock() on the uniprocessor kernel (it raises IRQL
to DISPATCH_LEVEL).
Comments?
Nate
I thought everyone did it that way. I only use spinlocks when absolutely
neccesary. Anywhere else
is too big a hammer for the nail at hand.
-Jeff
-----Original Message-----
From: Nate Bushman [mailto:xxxxx@powerquest.com]
Sent: Wednesday, November 05, 2003 6:09 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Using sync events rather than spinlocks…
I’ve often wondered why synchronization events aren’t commonly used in place
of spinlocks when all resource access is known to occur at IRQL <=
DISPATCH_LEVEL and no timeout on the wait is necessary. As long as the
event can be initialized at PASSIVE_LEVEL, the DDK says that it’s legal to
wait on and signal the event at IRQL <= DISPATCH_LEVEL. Am I missing
something here? This seems like a very good alternative to using spinlocks
for many scenarios. Especially if you want to avoid the effect of
KeAcquireSpinLock() on the uniprocessor kernel (it raises IRQL to
DISPATCH_LEVEL).
Comments?
Nate
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@concord.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
the latest virus scan software available for the presence of computer
viruses.
**********************************************************************
Well personally I would use a mutex in those cases, but Windows offers a
heck of a lot of syncronization mechanisms. The reason spinlocks are used
so often is that they are extremely low overhead versus most of the other
mechanisms.
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
----- Original Message -----
From: “Nate Bushman”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, November 05, 2003 6:09 PM
Subject: [ntdev] Using sync events rather than spinlocks…
I’ve often wondered why synchronization events aren’t commonly used in
place of spinlocks when all resource access is known to occur at IRQL <=
DISPATCH_LEVEL and no timeout on the wait is necessary. As long as the
event can be initialized at PASSIVE_LEVEL, the DDK says that it’s legal
to wait on and signal the event at IRQL <= DISPATCH_LEVEL. Am I missing
something here? This seems like a very good alternative to using
spinlocks for many scenarios. Especially if you want to avoid the
effect of KeAcquireSpinLock() on the uniprocessor kernel (it raises IRQL
to DISPATCH_LEVEL).
Comments?
Nate
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@acm.org
To unsubscribe send a blank email to xxxxx@lists.osr.com
Hmmm… At dispatch level you can wait only if timeout is set to zero
(which can’t be considered as wait at all). Considering that completion
routines “by default” (from design point of view) are called at dispatch
level you can’t avoid using spinlocks if you manage/access some lists
from the completion routine. For example, in FS filter drv one may add a
FO to the list in the completion routine for create and remove it in the
completion routine for close. Which, in turn, means that whenever you
access this list from any other place in your code you also must use a
spinlock?
-----Original Message-----
From: Nate Bushman [mailto:xxxxx@powerquest.com]
Sent: Wednesday, November 05, 2003 3:09 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Using sync events rather than spinlocks…
I’ve often wondered why synchronization events aren’t commonly used in
place of spinlocks when all resource access is known to occur at IRQL <=
DISPATCH_LEVEL and no timeout on the wait is necessary. As long as the
event can be initialized at PASSIVE_LEVEL, the DDK says that it’s legal
to wait on and signal the event at IRQL <= DISPATCH_LEVEL. Am I missing
something here? This seems like a very good alternative to using
spinlocks for many scenarios. Especially if you want to avoid the
effect of KeAcquireSpinLock() on the uniprocessor kernel (it raises IRQL
to DISPATCH_LEVEL).
Comments?
Nate
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as:
xxxxx@borland.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
FAST_MUTEX is used very often, and it is built on top of sync event.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Nate Bushman”
To: “Windows System Software Devs Interest List”
Sent: Thursday, November 06, 2003 2:09 AM
Subject: [ntdev] Using sync events rather than spinlocks…
> I’ve often wondered why synchronization events aren’t commonly used in
> place of spinlocks when all resource access is known to occur at IRQL <=
> DISPATCH_LEVEL and no timeout on the wait is necessary. As long as the
> event can be initialized at PASSIVE_LEVEL, the DDK says that it’s legal
> to wait on and signal the event at IRQL <= DISPATCH_LEVEL. Am I missing
> something here? This seems like a very good alternative to using
> spinlocks for many scenarios. Especially if you want to avoid the
> effect of KeAcquireSpinLock() on the uniprocessor kernel (it raises IRQL
> to DISPATCH_LEVEL).
>
> Comments?
>
> Nate
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
Uh, unless NT has radically changed, waiting on events at DISPATCH_LEVEL is
verboten and waiting at anything other than PASSIVE_LEVEL is discouraged.
You can only poll or signal an event at DISPATCH_LEVEL. Reread the DDK docs.
You must use spinlocks if any code segment requiring the lock (and blocking
if it cannot be acquired, which would cover about 99.999% of all
lock-acquiring code segments,) can execute at DISPATCH_LEVEL.
=====================
Mark Roddy
-----Original Message-----
From: Don Burn [mailto:xxxxx@acm.org]
Sent: Wednesday, November 05, 2003 6:23 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: Using sync events rather than spinlocks…
Well personally I would use a mutex in those cases, but
Windows offers a heck of a lot of syncronization mechanisms.
The reason spinlocks are used so often is that they are
extremely low overhead versus most of the other mechanisms.
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
----- Original Message -----
From: “Nate Bushman”
> To: “Windows System Software Devs Interest List”
> Sent: Wednesday, November 05, 2003 6:09 PM
> Subject: [ntdev] Using sync events rather than spinlocks…
>
>
> I’ve often wondered why synchronization events aren’t commonly used in
> place of spinlocks when all resource access is known to occur
> at IRQL <=
> DISPATCH_LEVEL and no timeout on the wait is necessary. As
> long as the
> event can be initialized at PASSIVE_LEVEL, the DDK says that
> it’s legal
> to wait on and signal the event at IRQL <= DISPATCH_LEVEL.
> Am I missing
> something here? This seems like a very good alternative to using
> spinlocks for many scenarios. Especially if you want to avoid the
> effect of KeAcquireSpinLock() on the uniprocessor kernel (it
> raises IRQL
> to DISPATCH_LEVEL).
>
> Comments?
>
> Nate
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@acm.org
> 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@stratus.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> -----Original Message-----
From: Roddy, Mark [mailto:xxxxx@stratus.com]
verboten
Isn’t it called forbidden or prohibited 
Regards
Volker
Not when it is Strictly Forbidden 
=====================
Mark Roddy
-----Original Message-----
From: Moebius, V. [mailto:xxxxx@baslerweb.com]
Sent: Thursday, November 06, 2003 10:06 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: Using sync events rather than spinlocks…
> -----Original Message-----
> From: Roddy, Mark [mailto:xxxxx@stratus.com]
> verboten
Isn’t it called forbidden or prohibited
Regards
Volker
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
ExAcquireFastMutex() and ExReleaseFastMutex() can’t be called at
DISPATCH_LEVEL. My question was about using sync events rather than
spinlocks to synchronize access to a resource when some accesses will be
at DISPATCH_LEVEL. I don’t see any reason why this can’t be done, and
yet I haven’t seen many (any) people use this technique. Everyone seems
to use spinlocks.
-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Wednesday, November 05, 2003 6:11 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: Using sync events rather than spinlocks…
FAST_MUTEX is used very often, and it is built on top of sync event.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Nate Bushman”
To: “Windows System Software Devs Interest List”
Sent: Thursday, November 06, 2003 2:09 AM
Subject: [ntdev] Using sync events rather than spinlocks…
> I’ve often wondered why synchronization events aren’t commonly used in
> place of spinlocks when all resource access is known to occur at IRQL
<=
> DISPATCH_LEVEL and no timeout on the wait is necessary. As long as
the
> event can be initialized at PASSIVE_LEVEL, the DDK says that it’s
legal
> to wait on and signal the event at IRQL <= DISPATCH_LEVEL. Am I
missing
> something here? This seems like a very good alternative to using
> spinlocks for many scenarios. Especially if you want to avoid the
> effect of KeAcquireSpinLock() on the uniprocessor kernel (it raises
IRQL
> to DISPATCH_LEVEL).
>
> Comments?
>
> Nate
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.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@powerquest.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Ah, that’s the tidbit I was missing. Duh. I read through the docs and
still missed it. Thanks Mark!
Nate
-----Original Message-----
From: Roddy, Mark [mailto:xxxxx@stratus.com]
Sent: Thursday, November 06, 2003 7:56 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: Using sync events rather than spinlocks…
Uh, unless NT has radically changed, waiting on events at DISPATCH_LEVEL
is
verboten and waiting at anything other than PASSIVE_LEVEL is
discouraged.
You can only poll or signal an event at DISPATCH_LEVEL. Reread the DDK
docs.
You must use spinlocks if any code segment requiring the lock (and
blocking
if it cannot be acquired, which would cover about 99.999% of all
lock-acquiring code segments,) can execute at DISPATCH_LEVEL.
=====================
Mark Roddy
-----Original Message-----
From: Don Burn [mailto:xxxxx@acm.org]
Sent: Wednesday, November 05, 2003 6:23 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: Using sync events rather than spinlocks…
Well personally I would use a mutex in those cases, but
Windows offers a heck of a lot of syncronization mechanisms.
The reason spinlocks are used so often is that they are
extremely low overhead versus most of the other mechanisms.
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
----- Original Message -----
From: “Nate Bushman”
> To: “Windows System Software Devs Interest List”
> Sent: Wednesday, November 05, 2003 6:09 PM
> Subject: [ntdev] Using sync events rather than spinlocks…
>
>
> I’ve often wondered why synchronization events aren’t commonly used in
> place of spinlocks when all resource access is known to occur
> at IRQL <=
> DISPATCH_LEVEL and no timeout on the wait is necessary. As
> long as the
> event can be initialized at PASSIVE_LEVEL, the DDK says that
> it’s legal
> to wait on and signal the event at IRQL <= DISPATCH_LEVEL.
> Am I missing
> something here? This seems like a very good alternative to using
> spinlocks for many scenarios. Especially if you want to avoid the
> effect of KeAcquireSpinLock() on the uniprocessor kernel (it
> raises IRQL
> to DISPATCH_LEVEL).
>
> Comments?
>
> Nate
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@acm.org
> 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@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@powerquest.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Nate,
That’s called an epiphany, and by definition that is when the stuff that hit
the rotating device, or fan, finally impacts your face. :))
–
Gary G. Little
Seagate Technologies, LLC
“Nate Bushman” wrote in message
news:xxxxx@ntdev…
Ah, that’s the tidbit I was missing. Duh. I read through the docs and
still missed it. Thanks Mark!
Nate
-----Original Message-----
From: Roddy, Mark [mailto:xxxxx@stratus.com]
Sent: Thursday, November 06, 2003 7:56 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: Using sync events rather than spinlocks…
Uh, unless NT has radically changed, waiting on events at DISPATCH_LEVEL
is
verboten and waiting at anything other than PASSIVE_LEVEL is
discouraged.
You can only poll or signal an event at DISPATCH_LEVEL. Reread the DDK
docs.
You must use spinlocks if any code segment requiring the lock (and
blocking
if it cannot be acquired, which would cover about 99.999% of all
lock-acquiring code segments,) can execute at DISPATCH_LEVEL.
=====================
Mark Roddy
> -----Original Message-----
> From: Don Burn [mailto:xxxxx@acm.org]
> Sent: Wednesday, November 05, 2003 6:23 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Re: Using sync events rather than spinlocks…
>
> Well personally I would use a mutex in those cases, but
> Windows offers a heck of a lot of syncronization mechanisms.
> The reason spinlocks are used so often is that they are
> extremely low overhead versus most of the other mechanisms.
>
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>
> ----- Original Message -----
> From: “Nate Bushman”
> To: “Windows System Software Devs Interest List”
> Sent: Wednesday, November 05, 2003 6:09 PM
> Subject: [ntdev] Using sync events rather than spinlocks…
>
>
> I’ve often wondered why synchronization events aren’t commonly used in
> place of spinlocks when all resource access is known to occur
> at IRQL <=
> DISPATCH_LEVEL and no timeout on the wait is necessary. As
> long as the
> event can be initialized at PASSIVE_LEVEL, the DDK says that
> it’s legal
> to wait on and signal the event at IRQL <= DISPATCH_LEVEL.
> Am I missing
> something here? This seems like a very good alternative to using
> spinlocks for many scenarios. Especially if you want to avoid the
> effect of KeAcquireSpinLock() on the uniprocessor kernel (it
> raises IRQL
> to DISPATCH_LEVEL).
>
> Comments?
>
> Nate
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@acm.org
> 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@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@powerquest.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
> DISPATCH_LEVEL. My question was about using sync events rather than
spinlocks to synchronize access to a resource when some accesses will be
at DISPATCH_LEVEL.
You cannot. Only spinlocks are available on DISPATCH_LEVEL.
I don’t see any reason why this can’t be done, and
Waiting on sync event blocks a thread, and this cannot be done on
DISPATCH_LEVEL.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com