Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Change thread safety annotations in TLS code
When I tried to build Envoy with Clang-18 I hit an issue that Clang thread safety analizer does not like the fact that we are returning a reference to a protected member (central_cache_) from centralCacheLockHeld method. While I do think that the code is correct, when looking at the thread safety annotations I think we could do a little bit better. Currently, centralCacheLockHeld is annotated with ABLS_ASSERT_EXCLUSIVE_LOCK. My understanding is that this annotation should be used on functions that during runtime check that the right lock is held and fail if it's not the case. centralCacheLockHeld currently does not actually check that the lock is held - this seems somewhat misleading and I don't think that thread safety analysis should derive anything from this annotation TBH, as there is no runtime check present there. We could add a runtime check to the function, but unfortunately it will not be enough to address Clang's warning (see llvm/llvm-project#123512). Besides I think that we can do slightly better. This change replaces ABLS_ASSERT_EXCLUSIVE_LOCK with ABSL_EXCLUSIVE_LOCKS_REQUIRED, to let Clang thread safety analysis know during compilation time that this function should be called under a lock. That change triggered a few more warnings in various places that call into centralCacheLockHeld. In simple cases just adding ABSL_EXCLUSIVE_LOCKS_REQUIRED to the functions that call centralCacheLockHeld was enough. There were a couple of more complicated cases that Clang could not figure out because it does not support aliasing (i.e., when the same mutex is known under different names, Clang cannot always figure out that different names refer to the same lock). To deal with those cases I added assertHeld method with ABLS_ASSERT_EXCLUSIVE_LOCK annotation to the lock implementation and used it to help Clang to figure out what locks are held. All-in-all, I think relying on ABSL_EXCLUSIVE_LOCKS_REQUIRED is slightly better and it addresses the warning for me as well. Signed-off-by: Mikhail Krinkin <mkrinkin@microsoft.com>
- Loading branch information