[PATCH] D65184: [Sema] Thread Safety Analysis: Fix negative capability's LockKind representation.

Aaron Puchert via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Jul 30 14:28:18 PDT 2019

aaronpuchert added a comment.

The primary purpose of Thread Safety Analysis is to make sure that accesses to shared resources are protected. That's why we only track whether a lock is available by default (i.e. without -Wthread-safety-negative), locks that we don't know anything about are assumed to be unlocked. As a side effect, we can detect double unlocks and lock/unlock-kind mismatches.

But we cannot detect double locks (and deadlocks) over function boundaries. This is why negative capabilities were introduced. But because not everybody cares about that enough to warrant more annotations, it's not on by default.

> Regarding why we should have types for negative capability, thinking about "exclusive !mu" in a reader-writer lock situation, which means "I am not trying to write". However, the code can still read.

Negative capabilities don't declare that we're not reading/writing: we can't do that without holding the actual (positive) capability anyway!

Having the capability `!mu` just means that we can assume `mu` is not locked. We will then usually acquire the `mu` (otherwise the annotation wouldn't be needed).




More information about the cfe-commits mailing list