<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=windows-1252">
</head>
<body>
<p>I've been working with -Wthread-safety, and have run into a few
rough edges. <br>
</p>
<p>One is RAII unlockers. As stated in the known limitations, it
doesn't handle an RAII unlocker and gets very confused, leading to
follow-on false positives. Is the only reasonable solution to
simply not annotating the RAII unlocker class, and live with the
analysis being wrong during the unlocked section?</p>
<p>Is there any ongoing work to resolve this issue?</p>
<p>I notice the work done by WebKit to use this functionality to do
static thread assertions
(<a class="moz-txt-link-freetext" href="https://webkit-search.igalia.com/webkit/source/Source/WTF/wtf/ThreadAssertions.h">https://webkit-search.igalia.com/webkit/source/Source/WTF/wtf/ThreadAssertions.h</a>).
There seems to be some value here (witness the shift from
lock-centric names), but examples on how to use it would be good,
similar to the mutex.h in the docs.</p>
<p>Related: There are a number of usage patterns for Mutexes that
don't lend themselves easily to thread-safety annotations. An
example would be a item written to from only a single thread, but
read from other threads. The lock must be held to write it, and
all off-writer-thread accesses must lock to access it. However,
on-writer-thread accesses *don't* need to lock, and will generate
false positives. (There are other Mutex patterns, like free
access until the item is made available to other threads, or after
all other threads are known to have exited, and more, which aren't
easily covered.)</p>
<p>What's the best way to handle this, other than not adding
GUARDED_BY() or using NO_THREAD_SAFETY_ANALYSIS? Could we mark an
item as requiring one of a set of capabilities? (i.e. on the
correct thread OR holds the mutex?)</p>
<p>Thanks,</p>
<p>Randell Jesup, Mozilla<br>
</p>
</body>
</html>