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

Mon Mar 9 08:35:20 PDT 2020

aaron.ballman added a comment.

In D72635#1911844 <https://reviews.llvm.org/D72635#1911844>, @aaronpuchert wrote:

> 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.

Okay, I think that makes sense, but is probably something we should mention explicitly in the thread safety documentation so we don't lose track of why this is the way it is. WDYT?

> 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).

Ah, interesting idea!

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

https://reviews.llvm.org/D72635