Thread-safety analysis rough edges


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


Randell Jesup, Mozilla