title: Is synchronizing with `std::mutex` slower than with `std::atomic(memory_order_seq_cst)`?
body: <p>The main reason for using atomics over mutexes, is that mutexes are expensive but with the default memory model for <code>atomics</code> being <code>memory_order_seq_cst</code>, isn't this just as expensive? </p>
  
  <p>Question: Can concurrent a program using locks be as fast as concurrent lock-free program?</p>
  
  <p>If so, it may not be worth the effort unless I want to use <code>memory_order_acq_rel</code> for atomics. </p>
  
  <hr>
  
  <p>Edit: 
  I may be missing something but lock-based cant be faster than lock-free because each lock will have to be a full memory barrier too. But with lock-free, it's possible to use techniques that are less restrictive then memory barriers. </p>
  
  <p>So back to my question, is lock-free any faster than lock based in new C++11 standard with default <code>memory_model</code>? </p>
  
  <p>Is "lock-free >= lock-based when measured in performance" true? Let's assume 2 hardware threads. </p>
  
  <hr>
  
  <p>Edit 2: 
  My question is not about progress guarantees, and maybe I'm using "lock-free" out of context. </p>
  
  <p>Basically when you have 2 threads with shared memory, and the only guarantee you need is that if one thread is writing then the other thread can't read or write, my assumption is that a simple atomic <code>compare_and_swap</code> operation would be much faster than locking a mutex. </p>
  
  <p>Because if one thread never even touches the shared memory, you will end up locking and unlocking over and over for no reason but with atomic operations you only use 1 CPU cycle each time.</p>
  
  <p>In regards to the comments, a spin-lock vs a mutex-lock is very different when there is very little contention. </p>