[PATCH] D72635: Allow arbitrary capability name in Thread Safety Analysis

[Aaron Puchert via Phabricator via cfe-commits]

aaronpuchert added a comment.

In D72635#1911671 <https://reviews.llvm.org/D72635#1911671>, @aaron.ballman wrote:

> However, do we want to diagnose when the capability strings are different?


Hmm, interesting question. The way I think about ordering capabilities is this: assuming I have more than one capability in my program, and occasionally I hold multiple capabilities at the same time. Then deadlocks can occur, unless I'm being careful. One way to avoid deadlocks is to have a partial order on capabilities that is a total order on the subsets of capabilities that are acquired together. It's not hard to see that this is sufficient, and I even think it's necessary. (In the sense that whenever I have a deadlock-free program, such an order exists. I have no proof for that, but that's just for lack of trying.)

Now if I acquire capabilities of different types, then the order also has to incorporate these different types. So my answer would be no, I think we have to allow this.

In fact (but that's for another change) I've even thought about warning when a cap. is acquired and it's not ordered with another already-held capability (under `-beta` of course).


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72635/new/

https://reviews.llvm.org/D72635