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

Reply via email to