[cfe-dev] Who is working on/has worked on Capability analysis (-Wthread-safety)?

[Aaron Puchert via cfe-dev]

Am 20.11.21 um 00:52 schrieb Randell Jesup:
> I've tried this.... it works better than without it, but there are 
> some oddities:
>
> In the test code (that's the only documentation for this?) [...]
>
Yes, for now it's not documented. The pattern is a bit weird, and we're 
not sure if and how we should support it.
>
> [...] both MutexAutoUnLock() and ~MutexAutoUnlock() are marked as 
> EXCLUSIVE_UNLOCK_FUNCTION()??
>
Almost. The constructor will mention the lock argument, so it's 
something like MutexAutoUnlock(Mutex &mutex) 
EXCLUSIVE_UNLOCK_FUNCTION(mutex), while the destructor's attribute will 
have no argument: ~MutexAutoUnlock() EXCLUSIVE_UNLOCK_FUNCTION(). 
Omitting the argument implies an implicit 'this', so the destructor is 
releasing the scoped capability.

When I designed this I extrapolated the handling of regular scoped 
locks, see https://bugs.llvm.org/show_bug.cgi?id=36162#c7 and 
https://bugs.llvm.org/show_bug.cgi?id=33504#c1. I guess this isn't 
ideal, and occasionally I have thoughts about changing that, but it's 
not easy without breaking existing code. (I don't think anybody is using 
scoped unlocking yet, since it's undocumented, but for consistency we'd 
also need to change scoped locking.)

> But if I make ~MutexAutoUnlock() EXCLUSIVE_LOCK_FUNCTION() (which 
> would make sense), I get more errors.
>
Exactly, that won't work.
>
> I still get a warning that "mutex 'mMutex' is still held at the end of 
> function" if I have:
>
> void foo() {
>    mMutex.AssertCurrentThreadOwns();  // where 
> AssertCurrentThreadOwns() has ASSERT_EXCLUSIVE_LOCK(this)
>    ....
>    {
>        MutexAutoUnlock unlock(mMutex);
>        ....
>    }
>    ....
> }
>
Seems like a bug, though not a surprising one. Asserted locks behave a 
bit strangely, because they don't have to (in fact should not) be 
released, and so we don't want in general allow them to join with 
acquired locks (which you have at the end of this scope). In this 
example it's fine though. We discussed about asserted locks a bit in 
https://reviews.llvm.org/D102026, and probably other places, but didn't 
develop a full understanding yet. Perhaps you can just file a bug? 
Otherwise I can also do it. There are some places where we should warn 
and others where we shouldn't, and perhaps they all have the same root 
cause.

Best regards,
Aaron