4 ms·

Overhead of std::mutex depends a lot on contention patterns. Assuming one x86 CPU socket, usually you can take + release an ideally optimized contended mutex ab

by vardump 11y ago

Overhead of std::mutex depends a lot on contention patterns. Assuming one x86 CPU socket, usually you can take + release an ideally optimized contended mutex about 10M-25M times per second, if that's all you do, 100% CPU usage on all cores. That's simply limited by how many times you can run contested LOCK XADD (x86 atomic fetch-and-add) / LOCK CMPXCHG* (x86 atomic compare-and-swap) instructions per second. Mutex generates a lot of cache coherency traffic and saturates the CPU internal ring bus. NUMA case it'll of course quickly saturate lower bandwidth CPU external QPI link(s). Contested mutexes perform a lot better on a typical laptop than on a server.

gpderetta 11y ago
good analysis, but you probably meant "ideally optimized uncontended mutex". edit: spelling
- vardump 11y ago
  To be exact, I meant code that just repeatedly locks and releases same mutex on all CPU cores. (Counting is a bit tricky, atomic counter on each lock would invalidate the results. Best to only update the counter, say, on every 1000th result or to use some parallel counting library.) for(;;) { mutex.lock(); mutex.unlock(); }
  - gpderetta 11y ago
    OK, now I see what you are saying. It would certainly be true for a spin lock, but it seems to me that, for std::mutex, the kernel transition required to arbitrate contention would dominate even on the coherency traffic, right?
    - vardump 11y ago
      Yeah, I was talking about spinlocks. You're right that context switches would dominate std::mutex. For some reason I was thinking std::mutex uses spinlocks, even though I knew better. Too much kernel side coding lately - context switches are often not possible there, so mutexes are often not possible as potential synchronization mechanisms.
      - gpderetta 11y ago
        You might still be right. The implementation of std::mutex is unspecified, and real world implementations will probably spin a bit before going into the kernel, so for your test case with a tiny critical section it might behave like a spinlock.

by vardump 11y ago

gpderetta 11y ago

good analysis, but you probably meant "ideally optimized uncontended mutex". edit: spelling

vardump 11y ago
To be exact, I meant code that just repeatedly locks and releases same mutex on all CPU cores. (Counting is a bit tricky, atomic counter on each lock would invalidate the results. Best to only update the counter, say, on every 1000th result or to use some parallel counting library.) for(;;) { mutex.lock(); mutex.unlock(); }
- gpderetta 11y ago
  OK, now I see what you are saying. It would certainly be true for a spin lock, but it seems to me that, for std::mutex, the kernel transition required to arbitrate contention would dominate even on the coherency traffic, right?
  - vardump 11y ago
    Yeah, I was talking about spinlocks. You're right that context switches would dominate std::mutex. For some reason I was thinking std::mutex uses spinlocks, even though I knew better. Too much kernel side coding lately - context switches are often not possible there, so mutexes are often not possible as potential synchronization mechanisms.
    - gpderetta 11y ago
      You might still be right. The implementation of std::mutex is unspecified, and real world implementations will probably spin a bit before going into the kernel, so for your test case with a tiny critical section it might behave like a spinlock.