title: Why does std::lock_guard release the lock after using std::adopt_lock?
body: <p>In the following example, the method <code>foo()</code> gets called, where it acquires ownership of a mutex, and locks it. It then calls <code>check()</code>, which acquires ownership, but assumes that the mutex is already locked, and so simply adopts it using <code>std::adopt_lock</code>.</p>
  
  <p>But when <code>check()</code> finishes, the mutex gets unlocked. So when <code>foo()</code> continues, the section I was trying to guard is actually no longer guarded.</p>
  
  <pre><code>#include &lt;mutex&gt;
  static std::mutex sessionLock;
  
  bool check();
  
  void foo() {
    std::lock_guard&lt;std::mutex&gt; guard(sessionLock);
    if (check()) {
      // Do transaction
      // Wait... the mutex is unlocked here!
    }
  }
  
  bool check() {
    std::lock_guard&lt;std::mutex&gt; guard(sessionLock, std::adopt_lock);
    // Critical section
    return true;
  }
  
  int main() {
    foo();
    return 0;
  }
  </code></pre>
  
  <p>I find this behaviour very unintuitive. If a sub-method decides to take ownership of a lock using <code>std::adopt_lock</code> (ie. it doesn't call <code>lock()</code>), shouldn't it also release ownership without calling <code>unlock()</code>? The standard says otherwise, but I'm curious if this was an oversight or if there is a particular reason this is expected.</p>
  
  <p>This could be rewritten using <code>std::recursive_mutex</code>, though in this case where a regular <code>std::mutex</code> is used, is there a proper way inside <code>check()</code> to ensure its critical section is guarded?</p>