title: Is this a correct use of ``memory_order_relaxed``?
body: <p>I am starting to use (sparingly) the atomic primitives introduced in C++11. A very simple use case is that of using <code>std::atomic&lt;integral&gt;</code> in a global <code>settings</code> class that stores the runtime configuration of my application.</p>
  
  <p>This class has a bunch of static methods to access global variables initialised at program startup. Previously the access to these global variables was protected by a <code>mutex</code>:</p>
  
  <pre><code>#include &lt;mutex&gt;
  
  class settings
  {
      static unsigned get_n_threads()
      {
          std::lock_guard&lt;std::mutex&gt; lock(s_mutex);
          return s_n_threads;
      }
      static std::mutex s_mutex;
      static unsigned   s_n_threads;
  };
  </code></pre>
  
  <p>With <code>std::atomic</code>, I have now:</p>
  
  <pre><code>#include &lt;atomic&gt;
  
  class settings
  {
      static unsigned get_n_threads()
      {
          return s_n_threads.load();
      }
      static std::atomic&lt;unsigned&gt; s_n_threads;
  };
  </code></pre>
  
  <p>Now, I was reading about the memory order specifications for atomic operations here: <a href="http://en.cppreference.com/w/cpp/atomic/memory_order" rel="nofollow">http://en.cppreference.com/w/cpp/atomic/memory_order</a></p>
  
  <p>It seems like for this very trivial use case scenario, I could modify the <code>load()</code> call to this:</p>
  
  <pre><code>return s_n_threads.load(std::memory_order_relaxed);
  </code></pre>
  
  <p>Note that the only requirement here is that the operations of inspecting and/or changing a global setting have to be atomic. These operations are not part of any lock-free algorithm and they do not need to be sequenced with anything (at least currently).</p>
  
  <p>From some research I have done, it looks like the consensus is to avoid relaxed operations unless one is an expert (which evidently I am not :), so I was wondering which pitfall (if any) I could fall into by applying this change.</p>