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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
