---

yaml
---
r: 14378
b: refs/heads/try
c: 9f49293
h: refs/heads/master
v: v3

Author: cpeterso

[refs]

@@ -2,5 +2,5 @@
 refs/heads/master: 61b1875c16de39c166b0f4d54bba19f9c6777d1a
 refs/heads/snap-stage1: e33de59e47c5076a89eadeb38f4934f58a3618a6
 refs/heads/snap-stage3: 4a81779abd786ff22d71434c6d9a5917ea4cdfff
-refs/heads/try: 159dfd7c3b9ea12a4d83c99c1eaa121f4be605c3
+refs/heads/try: 9f492932324aded094042759eeb5824c64aa98e0
 refs/tags/release-0.1: 1f5c5126e96c79d22cb7862f75304136e204f105

branches/try/src/rt/sync/lock_and_signal.cpp

@@ -19,7 +19,18 @@ lock_and_signal::lock_and_signal()
     : _holding_thread(INVALID_THREAD)
 {
     _event = CreateEvent(NULL, FALSE, FALSE, NULL);
-    InitializeCriticalSection(&_cs);
+
+    // If a CRITICAL_SECTION is not initialized with a spin count, it will
+    // default to 0, even on multi-processor systems. MSDN suggests using
+    // 4000. On single-processor systems, the spin count parameter is ignored
+    // and the critical section's spin count defaults to 0.
+    const DWORD SPIN_COUNT = 4000;
+    CHECKED(!InitializeCriticalSectionAndSpinCount(&_cs, SPIN_COUNT));
+
+    // TODO? Consider checking GetProcAddress("InitializeCriticalSectionEx")
+    // so Windows >= Vista we can use CRITICAL_SECTION_NO_DEBUG_INFO to avoid
+    // allocating CRITICAL_SECTION debug info that is never released. See:
+    // http://stackoverflow.com/questions/804848/critical-sections-leaking-memory-on-vista-win2008#889853
 }
 
 #else