<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jun 6, 2014 at 9:52 AM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>By the way, there's another approach I could have taken, which is simply to delete llvm::sys::Mutex entirely, and embed std::mutex and std::recursive_mutex instances directly in the code.  We lose the Debug versions of the mutexes, but they seem to be not used heavily, so maybe this is ok.  I took the path of least resistance and made the semantics identical though, so if you think this other approach is better, I could change it.<br>
</div></div></div></div></blockquote><div><br></div><div>Just to expand on this line of thought, a mutex's cost is directly proportional to how heavily contended it is.  If there's zero contention, which there will be in a single threaded app, locking a mutex is almost free.  So I don't see too much of a problem with getting rid of this whole concept of multi-threading only mode and going with raw std::mutex / recursive_mutex in the code.  But let me know if there's something I haven't considered or if anyone feels differently.</div>
</div><br></div></div>