The documentation I have suggests that spin locks are
the way to go for serialization in a multi-processor
environment, but that they should only encapsulate a
minimal amount of code (such as incrementing a
variable). Does this mean that other locking
primitives such as fast mutexes are not thread safe in
a multi-processor environment? The application I have
requires a “critical section†lock for a port from
user to kernel space, and the client wants to preserve
the original semantics.
Cheers
Dave
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Spinlocks are appropriate, and in fact are required, when any thread that may attempt to acquire the lock will do so at DISPATCH_LEVEL or DIRQL. Conversely, the other synchronization mechanisms are appropriate when these conditions are not present: the threads will always be executing at less than DISPATCH_LEVEL (and really at PASSIVE_LEVEL). All of the non-spinlock synchronization mechanisms (fast mutexes event objects etc.) are MP safe.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Dave B. Sharp
Sent: Wednesday, May 24, 2006 6:14 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Spin locks and other locking primitives
The documentation I have suggests that spin locks are
the way to go for serialization in a multi-processor
environment, but that they should only encapsulate a
minimal amount of code (such as incrementing a
variable). Does this mean that other locking
primitives such as fast mutexes are not thread safe in
a multi-processor environment? The application I have
requires a “critical section†lock for a port from
user to kernel space, and the client wants to preserve
the original semantics.
Cheers
Dave
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
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
Acquiring a spinlock will raise you to DISPATCH_LEVEL, at a minimum, or DIRQL depending upon which function you use and whether you need to sync to D_L or DIRQL. Other locking mechanisms in the kernel are used BELOW D_L. It’s really not a matter, in this case, of what the client wants to preserve, it is a matter of what the kernel requires.
You can always put some silly little wrappers around your synchronization mechanisms, but mostly those simply obfuscate the issue and can easily confuse the next poor dumb schmuck that has to support the code.
Gary G. Little
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Dave B. Sharp
Sent: Wednesday, May 24, 2006 8:14 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Spin locks and other locking primitives
The documentation I have suggests that spin locks are
the way to go for serialization in a multi-processor
environment, but that they should only encapsulate a
minimal amount of code (such as incrementing a
variable). Does this mean that other locking
primitives such as fast mutexes are not thread safe in
a multi-processor environment? The application I have
requires a “critical section†lock for a port from
user to kernel space, and the client wants to preserve
the original semantics.
Cheers
Dave
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
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
Thanx Mark, Much appreciated.
Cheers
Dave
— Mark Roddy wrote:
> Spinlocks are appropriate, and in fact are required,
> when any thread that may attempt to acquire the lock
> will do so at DISPATCH_LEVEL or DIRQL. Conversely,
> the other synchronization mechanisms are appropriate
> when these conditions are not present: the threads
> will always be executing at less than DISPATCH_LEVEL
> (and really at PASSIVE_LEVEL). All of the
> non-spinlock synchronization mechanisms (fast
> mutexes event objects etc.) are MP safe.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf
> Of Dave B. Sharp
> Sent: Wednesday, May 24, 2006 6:14 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Spin locks and other locking
> primitives
>
>
> The documentation I have suggests that spin locks
> are
> the way to go for serialization in a multi-processor
> environment, but that they should only encapsulate a
> minimal amount of code (such as incrementing a
> variable). Does this mean that other locking
> primitives such as fast mutexes are not thread safe
> in
> a multi-processor environment? The application I
> have
> requires a “critical section†lock for a
> port from
> user to kernel space, and the client wants to
> preserve
> the original semantics.
> Cheers
> Dave
>
>
>
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam
> protection around
> http://mail.yahoo.com
>
> —
> 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
>
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Spinlocks are only one tool in the shed. They solve a specific problem, as
others have responded. I recommend that you read the following whitepaper
to understand various locking primitives. They all work in both multi- and
uni-processor environments.
http://www.microsoft.com/whdc/driver/kernel/locks.mspx
–
Jake Oshins
Windows Kernel Group
The Virtual Machine Team at Microsoft is hiring. Contact
xxxxx@microsoft.com for more information.
This posting is provided “AS IS” with no warranties, and confers no rights.
“Dave B. Sharp” wrote in message news:xxxxx@ntdev…
>
> The documentation I have suggests that spin locks are
> the way to go for serialization in a multi-processor
> environment, but that they should only encapsulate a
> minimal amount of code (such as incrementing a
> variable). Does this mean that other locking
> primitives such as fast mutexes are not thread safe in
> a multi-processor environment? The application I have
> requires a â?ocritical sectionâ? lock for a port from
> user to kernel space, and the client wants to preserve
> the original semantics.
> Cheers
> Dave
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> variable). Does this mean that other locking
primitives such as fast mutexes are not thread safe in
a multi-processor environment?
No, they are also thread-safe, even on SMP, just not usable on >=
DISPATCH_LEVEL.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com