timming of spinlock and mutex/semaphore acquire and release:

NTDEV
1

Needing only rough figures, can I assume that acquiring and releasing spinglocks and mutex/semaphores normally takes sub microsecond on today’s processors.

thanks,

2

is the lock under heavy contention ?

From: xxxxx@lists.osr.com [xxxxx@lists.osr.com] on behalf of xxxxx@yahoo.com [xxxxx@yahoo.com]
Sent: Tuesday, May 31, 2011 11:03 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] timming of spinlock and mutex/semaphore acquire and release:

Needing only rough figures, can I assume that acquiring and releasing spinglocks and mutex/semaphores normally takes sub microsecond on today’s processors.

thanks,

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

3

No. This is for the case of zero contention: always avialable, always signaled.

4

> No. This is for the case of zero contention: always avialable, always signaled.

Then FAST_MUTEX is single interlocked op on each acquire and release.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

5

But I need to be able to block after acquiring the mutex, waiting for synch i/o.

6

If you need to wait for sync io, a spinlock is not even in the discussion. You can still use a FAST_MUTEX, even use the Unsafe acquire and release calls, if you enter and exit a critical region before acquisition and after releasing the fast mutex

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Tuesday, May 31, 2011 12:29 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] timming of spinlock and mutex/semaphore acquire and release:

But I need to be able to block after acquiring the mutex, waiting for synch i/o.

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

7

I grab a mutex to serialize access to h/w.
I use spinlock to serialize access to driver context. Never hold the spinlock when calling outside the driver.

My motive is to convince other players on my team that in a contention free setting, acquiring a mutex, fast or otherwise is a sub microsecond operation.

8

And if it is not? What are you going to do? Not use a lock at all? It sounds like you are micro optimizing here and not focusing on getting the functionality right. You cannot do perf analysis by guessing and looking at specific lock times. You need to create the system you want to analyze and then actually analyze it to see where the hotpaths are. Don’t guess where the hotpaths are, 99% of the time you will guess wrong

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Tuesday, May 31, 2011 1:13 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] timming of spinlock and mutex/semaphore acquire and release:

I grab a mutex to serialize access to h/w.
I use spinlock to serialize access to driver context. Never hold the spinlock when calling outside the driver.

My motive is to convince other players on my team that in a contention free setting, acquiring a mutex, fast or otherwise is a sub microsecond operation.

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

9

Just to amplify what Doron said:

I’ve learned quite a few useful things since I started writing drivers back in the days of wooden computers… and one of the most useful of those things is that performance optimization – except for the REALLY low-hanging fruit – is one of the LEAST intuitive things once will ever encounter. Don’t guess, you’ll guess wrong.

Peter
OSR