aaronpuchert added a comment.

In https://reviews.llvm.org/D49355#1188603, @phosek wrote:

> In https://reviews.llvm.org/D49355#1188520, @aaronpuchert wrote:
>
> > Could you explain what annotations like `LOCK_UNLOCK` are useful for? What 
> > do they check? The annotation should certainly not be necessary.
> >
> > Shouldn't you just use `REQUIRES(!...)` or `EXCLUDES(...)`? If a function 
> > locks and unlocks a mutex, I don't see a reason to have annotations on it, 
> > other than for preventing double locks. But for that we have negative 
> > capabilities.
>
>
> The purpose here indeed is to avoid double locks. I tried using 
> `EXCLUDES(...)` but that doesn't work because `RegisterIsolatePortWithName` 
> <https://github.com/flutter/engine/blob/master/lib/ui/isolate_name_server/isolate_name_server.h#L31>
>  calls `LookupIsolatePortByNameUnprotected` 
> <https://github.com/flutter/engine/blob/master/lib/ui/isolate_name_server/isolate_name_server.h#L39>
>  which has `EXCLUSIVE_LOCKS_REQUIRED(...)` annotation. I also tried using the 
> negative annotation but that reports far too many warnings in the existing 
> code which makes it unusable.
>
> I'm fine changing the code, but unless there's a simple workaround I'd still 
> argue for a revert, because the change even if correct has broken an existing 
> usage pattern that worked fine for a long time before and is used in large 
> codebases.


Can you explain in more detail what doesn't work? If you lock `mutex_` in the 
former function, the analysis should register that anyway and don't complain 
about calling the latter. The `LOCK_UNLOCK` annotation should be equivalent to 
`EXCLUDES(mutex_)` in that regard, too. There should also not be a difference 
regarding callers of the former function, in both cases the attributes don't 
propagate.

You should be aware that `LOCK_UNLOCK` does **not** prevent double-locking. If 
that is your concern, use negative annotations, i.e. `REQUIRES(!mutex_)` and 
`-Wthread-safety-negative`. Yes, that likely produces some more warnings, but 
not outside the class since `mutex_` is a private member.

Having `LOCK_UNLOCK` annotations doesn't seem to be intended, because one 
should neutralize the other. There was no example in the documentation, and 
apparently also no test in `test/SemaCXX/warn-thread-safety-analysis.cpp`. You 
should use `EXCLUDES` instead, or if you care enough about avoiding double 
locking, `REQUIRES(!...)`.


Repository:
  rC Clang

https://reviews.llvm.org/D49355



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to