<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jul 27, 2017 at 10:32 AM, Hans Wennborg <span dir="ltr"><<a href="mailto:hans@chromium.org" target="_blank">hans@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5">On Thu, Jul 27, 2017 at 10:04 AM, Marshall Clow via cfe-dev<br>
<<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
> In C++17, we introduced a new variadic class called scoped_lock.<br>
> It took a set of mutexes, and locked them all (in the constructor) and<br>
> unlocked them all (in the destructor).  It also has an option to "adopt" the<br>
> locks (i.e, you can pass it already locked mutexes and it will not lock them<br>
> again).<br>
><br>
> The constructors look like this (as originally defined):<br>
><br>
> class scoped_lock {<br>
> ...<br>
>     explicit scoped_lock(MutexTypes&... m);<br>
>     scoped_lock(MutexTypes&... m, adopt_lock_t);<br>
> ...<br>
> };<br>
><br>
> but this caused some problems with template deduction (specifically in<br>
> deduction guides)<br>
> So, at the last minute in the C++17 cycle, the committee decided to change<br>
> the second constructor to take the `adopt_lock` flag AT THE START.<br>
><br>
> class scoped_lock {<br>
> ...<br>
>     explicit scoped_lock(MutexTypes&... m);<br>
>     scoped_lock(adopt_lock_t, MutexTypes&... m);<br>
> ...<br>
> };<br>
><br>
> scoped_lock is a new feature in C++17, and so the installed base of people<br>
> using it should be very small. There are no uses of it in the LLVM code base<br>
> outside of the libc++ test suite.<br>
><br>
> I'm going to make this change to bring libc++ in conformance with the<br>
> (hopefully final) standard, and people who are using the old call will have<br>
> to update their code. Sorry about that.<br>
<br>
</div></div>Was r298681 the first commit that added scoped_lock? If so it hasn't<br>
shipped in any LLVM releases yet, and perhaps we should merge the<br>
upcoming fix to 5.0.0?<br><br></blockquote><div><br></div><div>Committed as revision 309296 </div></div>I'll watch the bots and let you know when it's ready to be merged into 5.0</div><div class="gmail_extra"><br></div><div class="gmail_extra">-- Marshall</div><div class="gmail_extra"><br></div></div>