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). Repository: rL LLVM CHANGES SINCE LAST ACTION https://reviews.llvm.org/D65184/new/ https://reviews.llvm.org/D65184 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
