ziangwan added a comment. The problem is: by the current state of the thread safety analysis, `ASSERT_SHARED_CAPABILTIY(!mu)` introduces a shared negative capability, whereas `RELEASE(mu)` **and `RELEASE_SHARED(mu)`** introduce an exclusive negative capability, and `UNLOCK_FUNCTION(mu)` introduces a generic negative capability. All three are different. At merge points, warnings will be issued if different types of negative capability are merged. The current thread safety analysis produces bogus false positive in our code base.
The solution I propose is that we should at least make `RELEASE_SHARED(mu)` produce a shared negative capability. 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. In other words, "exclusive !mu" does not imply "shared !mu", and the code can still hold the lock in shared state. Without the types of negative capability, we wouldn't be able to express the situation described above. 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
