<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Nov 10, 2016 at 7:07 AM, christoph@ruediger.engineering <span dir="ltr"><<a href="mailto:christoph@ruediger.engineering" target="_blank">christoph@ruediger.<wbr>engineering</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am 09.11.16, 20:31 schrieb "Richard Trieu" <<a href="mailto:rtrieu@google.com" target="_blank">rtrieu@google.com</a>>:<br>
<span><br>
>It looks like you are running into the limits of what has been implemented for thread safety analysis.  It doesn't look like SCOPED_CAPABILITY supports unlocking and relocking the mutex.  In these cases, the usual way to use a locking<br>
> class is to do something like:<br>
><br>
><br>
>int main(int argc, char const *argv[]) {<br>
>  {<br>
>    unique_lock lock(mtx);<br>
>    any_number = 42;<br>
>  }<br>
>  int i = increment();<br>
><br>
>  unique_lock lock(mtx);<br>
>  return i;<br>
>}<br>
<br>
</span>Using just a basic lock like std::lock_guard (or the MutexLocker from the documentation), we have to use condition_variable_any instead of condition_variable and hand over the bare mutex instead of std::lock_guard (or the MutexLocker). Just for the sake of completeness, here is how this is supposed to be written, if I understand it right:<br>
<br>
// Using the already annotated libc++ here<br>
std::mutex mtx;<br>
std::condition_variable_any cv;<br>
<br>
void someFunction() {<br>
  std::lock_guard<std::mutex> lock(mtx);<br>
  while (!active) {<br>
    cv.wait(mtx);<br>
  }<br>
  // Do something...<br>
}<br>
<br>
If this is the intended use case, maybe there should be something in the documentation. Because this is what boost and later C++11 have tought the people (Don’t use free mutexes), at least to my understanding. I will add something to the documentation and provide a patch.<br>
<br>
I’ve tried to understand the thread safety analysis in clang, but after an hour of looking at the code, this is still a beast and I haven’t found the handle to start off. So from my point of view, there is no short fix available. However, the static analyzer is able to track references of variables, but implementing this into the thread safety analyzer is understanding both of them. I get back to the list with a patch proposal in a year or so... ☺<br>
<span><br>
<br>
>The limitations section also says that it doesn't track pointer aliases:<br>
><a href="http://clang.llvm.org/docs/ThreadSafetyAnalysis.html#no-alias-analysis" rel="noreferrer" target="_blank">http://clang.llvm.org/docs/Th<wbr>readSafetyAnalysis.html#no-ali<wbr>as-analysis</a><br>
<br>
</span>After re-reading this section, it states clearly that only the example MutexLocker pattern is implemented and nothing else. So my fault, sorry.<br>
<br>
Thanks for your help here.<br>
<span class="m_9120115673710306648HOEnZb"><font color="#888888"><br>
-Christoph<br>
<br>
</font></span></blockquote></div><br></div><div class="gmail_extra">I haven't used condition variables with thread safety analysis so I can't comment on how well they work together.  If you want to work on the thread safety analysis in Clang, you could possibly contact Delesley and see if he has any good starter projects to work on.</div></div>