Eric Bron (eric.bron.delete@this.zvisuel.privatefortest.com) on December 6, 2014 7:07 am wrote:
> > with the following results:
> >
> > Iterations: 1000000
> > Thread count: 1
> > std::mutex: 52002us
> > std::recursive_mutex: 51002us
> > CRITICAL_SECTION: 23001us
> > Thread count: 2
> > std::mutex: 448025us
> > std::recursive_mutex: 442025us
> > CRITICAL_SECTION: 106006us
> > Thread count: 4
> > std::mutex: 884050us
> > std::recursive_mutex: 893051us
> > CRITICAL_SECTION: 197011us
> > Thread count: 8
> > std::mutex: 70695043us
> > std::recursive_mutex: 73504204us
> > CRITICAL_SECTION: 273015us
> > Thread count: 16
> > std::mutex: 147516437us
> > std::recursive_mutex: 156276938us
> > CRITICAL_SECTION: 440025us
> >
>
> very interesting, thank you, it looks it contradicts what nksingh was writing and it's
> certainly not a good idea to revise my code based on critical sections (very clean with
> a Lock class were the destructor leave the CS) with C++ std mutexes and locks

Thanks for collecting the perf results. The reason the std::mutex is about twice as expensive as a CS is that it uses a CS internally to lock its state so a single mutex lock/unlock pair requires 4 CS lock/unlocks. 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.

This has been enlightening for me.