[cfe-dev] Thread-safety analysis rough edges

[Randell Jesup via cfe-dev]

(resend)

I've been working with -Wthread-safety, and have run into a few rough 
edges.

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?

Is there any ongoing work to resolve this issue?

I notice the work done by WebKit to use this functionality to do static 
thread assertions 
(https://webkit-search.igalia.com/webkit/source/Source/WTF/wtf/ThreadAssertions.h). 
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.

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.)

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?)

Thanks,

Randell Jesup, Mozilla
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20211027/ded97ba8/attachment.html>