<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 6, 2014 at 10:57 PM, Kostya Serebryany <span dir="ltr"><<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>As for the deadlocks, indeed it is possible to add deadlock detection directly to std::mutex and std::spinlock code. </div>

<div>It may even end up being more efficient than a standalone deadlock detector -- </div><div>but only if we can add an extra word to the mutex/spinlock object.</div><div>The deadlock detector's overhead comes primarily from two tasks: </div>

<div>  1. get the metadata for the lock in question. </div><div>  2. query the lock-acquisition-order graph to see if there is a loop. </div><div><br></div><div>If the lock-acquisition-order graph is sparse (99% of cases we've seen), then the task #<span class="aBn" tabindex="0"><span class="aQJ">1 may</span></span> constitute  up to 50% of the overhead.</div>

<div>If we can add a word to std::mutex/std::spinlock data structures then the task #1 becomes trivial.</div></blockquote></div></div><br><div>I don't see any reason not to reserve a word in the mutex so that in (an ABI-compatible) debug build the mutex can support deadlock detection. Some people are super concerned about having an extra word in a mutex, but I'm not at all.</div>
<div><br></div><div>For libc++, it would probably need to be behind an ABI-breaking macro on Mac and FreeBSD, but we haven't committed to any ABI stability on Linux, so we could probably enable it by default there, and get into build bots.</div>
<div><br></div><div>Maybe bring this up on the cfe-dev list to discuss with Marshall and other folks interested in libc++?</div></div>