> Thanks for collecting the perf results.

just to make it clear, these are the perf results in the GiGNiC post (with undisclosed compiler version and test platform), not something I have tested personnaly


>The reason the std::mutex is about twice as expensive
> as a CS

this isn't always twice, far from it (see timings for 16 threads) from GiGNiC's timings:

thread count   std::mutex time (us)   CRITICAL_SECTION time (us)   CS speedup

      2              52002                   23001                    ~2.26 

      4             448025                  106006                    ~4.2

      8             893051                  197011                    ~4.5 

     16          147516437                  440025                  ~335

is that it uses a CS internally to lock its state so a single mutex lock/unlock
> pair requires 4 CS lock/unlocks. you mean a sequence such as

EnterCriticalSection(cs1);
EnterCriticalSection(cs2);
LeaveCriticalSection(cs2);
LeaveCriticalSection(cs1);

I suppose, but it will not explain the timings with reported with wild variations of the speedup factor


>I guess I should have a conversation with the CRT owners about making this cheaper so that there's no reason to use your own wrappers.

from your comment I suppose that you work in the VC++ team, right ?