Windows File Locking ASP.NET Semaphore C++ Example Code: There are several different methods of atomically locking code and data on a Microsoft Windows platform. The primary purpose of this whitepaper is to give developers a brief introduction to the different methods of locking in Windows and the associated performance costs associated with those locks. This information is particularly applicable since future architectures will be multi-core.

---

by Michael Chynoweth and Mary R Lee

Abstract

There are several different methods of atomically locking code and data on a Microsoft Windows platform. The primary purpose of this whitepaper is to give developers a brief introduction to the different methods of locking in Windows and the associated performance costs associated with those locks. This information is particularly applicable since future architectures will be multi-core.

Introduction

Multi-threading software applications is critical for increasing performance for Intel’s Core Architecture. Locking code can frequently be the most frequently run code in a multi-threaded application. Determining which methodology of locking to utilize can be as critical as identification of parallelism within an application. The primary purpose of this whitepaper is to give developers a brief introduction to the different methods of locking in Windows and the associated performance costs associated with those locks. Some Window’s locking APIs have the possibility of jumping into the operating system kernel. This white-paper will detail which ones jump into the kernel and under which conditions.

Two different locking kernels are used to demonstrate the impact of locks representing different granularities. The first locking kernel emulates a scenario of locking and unlocking a dynamically linked list which would commonly be used to maintain a freelist by a memory manager. For a multi-threaded application, it would be necessary to first lock the list before a thread attempts to malloc or free memory. The second locking kernel represents a more granular lock in that it simply obtains the ThreadID of the thread which has obtained the lock, updates a global variable, and then releases the lock. The performance of the different locks under low and high contention scenarios is tested through scaling the number from 1 to 64 threads. Each thread obtains the lock 10,000,000 times performs an operation and then releases the lock. The OS timing has been changed for Windows XP from 10 ms to 1 ms for these experiments.