melver wrote:
> On a related note, do we emit `-Wthread-safety-negative` for reentrant locks?
> I don't remember that we carved out an exception for that, and we probably
> should.
We do - and it's deliberate on my part as I've been trying to indicate that
there might be valid use cases for that. While conceptually contradictory,
there might be cases where developers want to ensure a reentrant mutex is NOT
held before entering a function.
I'll give you an example:
```
class Example {
ReentrantMutex mu;
...
// Performs heavy I/O (write to file), blocking many seconds...
void expensiveIO(..) REQUIRES(!mu);
};
```
While technically ok to enter expensiveIO() with the mutex held, it would
prohibit forward-progress in other threads. This is a liveness bug, and
negative capabilities can help catch such cases, too. While `EXCLUDES(..)` can
also help, I do like negative capabilities for their strictness. Whether or not
the developer is able to use a non-reentrant Mutex here is a different question
- but e.g. more uncommon synchronization mechanisms like interrupt locking,
preemption locking, or RCU fundamentally are reentrant.
I would like to account for OS kernel code needs, too (RCU also exists for user
space).
https://github.com/llvm/llvm-project/pull/141599
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
