Can scoped_lock lock a shared_mutex in read mode? : <p>C++17 introduced both <code>std::shared_mutex</code> and <code>std::scoped_lock</code>. My problem is now, that it seems, that <code>scoped_lock</code> will lock a shared mutex always in exclusive (writer) mode, when it is passed as an argument, and not in shared (reader) mode. In my app, I need to update an object <code>dst</code> with data from an object <code>src</code>. I want to lock <code>src</code> shared and <code>dst</code> exclusive. Unfortunately, this has the potential for deadlock, if a call to another update method with <code>src</code> and <code>dst</code> switched occurs at the same time. So I would like to use the fancy deadlock avoidance mechanisms of <code>std::scoped_lock</code>.</p>

<p>I could use <code>scoped_lock</code> to lock both <code>src</code> and <code>dst</code> in exclusive mode, but that unnecessarily strict lock has performance backdraws elsewhere. However, it seems, that it is possible to wrap <code>src</code>'s <code>shared_mutex</code> into a <code>std::shared_lock</code> and use that with the <code>scoped_lock</code>: When the <code>scoped_lock</code> during its locking action calls <code>try_lock()</code> on the <code>shared_lock</code>, the later will actually call <code>try_shared_lock()</code> on <code>src</code>'s <code>shared_mutex</code>, and that's what I need.</p>

<p>So my code looks as simple as this:</p>

<pre><code>struct data {
    mutable std::shared_mutex mutex;
    // actual data follows
};

void update(const data&amp; src, data&amp; dst)
{
    std::shared_lock slock(src.mutex, std::defer_lock);
    std::scoped_lock lockall(slock, dst.mutex);
    // now can safely update dst with src???
}
</code></pre>

<p>Is it safe to use a (shared) lock guard like this inside another (deadlock avoidance) lock guard?</p>
