Today a discussion came up regarding the overhead of a Win32 CRITICAL_SECTION object, and I did some digging to find out how they actually work. These objects are used for synchronization by threads in a single process (they don't work across process boundaries), and they are very fast in the absense of contention because no context switch is required.
But they're still not free: In addition to the 20 bytes or so taken up by the CRITICAL_SECTION object itself, I'd always knew that a kernel object was used somehow, and the structure member LockSemaphore (a HANDLE) certainly suggested that it's a Semaphore.
But it's not: It's an Event object, and it's only allocated the first time actual contention takes place. This means that it's fast and lightweight in the usual case, and only when contention occurs is the overhead of an additional kernel object allocated. Then it's a matter of WaitForSingleObject() to get access to the critical section.
This suggests that the slowest operation is the first time a critical section object has contention, when the event object must be allocated, but after that it's smooth sailing.
I'd not seen this anywhere and thought it ought to be memorialized.
Comments