Concept ACK (in the light of #20272 discussion).

This change reverts the @ajtowns's idea for AssertLockNotHeld but I cannot see the way to save it, unfortunately.

Approach ACK, +1 on doc change as well

This change reverts

Correct, but the revert is only temporary (until cs_main is removed or a private member)

Force pushed to address feedback

utACK fa5eabe

ACK fa5eabe

This silenced the compiler warnings at the time, so it was ok. I just wonder about the following reasoning, in the light of #24931:

Remove negative lock annotations from globals ... They only make sense for mutexes that are private members.

Why is that? For example:

Mutex g_mutex;

void f1()
{
    LOCK(g_mutex);
}

void f2()
{
    LOCK(g_mutex);
    f1();
}

This is undefined behavior that would be detected if f1() is annotated with EXCLUSIVE_LOCKS_REQUIRED(!g_mutex).

To me it looks like that negative lock annotations "make sense" regardless of the scope of the mutex, no?

This pull was done in light of #20272 (comment) . If #24931 fixes the mentioned issues, then that is fine.

@vasild The problem is when you call f1 -- the negative annotation needs to keep getting propogated up the call stack:

Mutex g_mutex;
void f1() EXCLUSIVE_LOCKS_REQUIRED(!g_mutex)
{
    LOCK(g_mutex);
}

class X {
private:
    Mutex m_mut;
public:
    void f1() EXCLUSIVE_LOCKS_REQUIRED(!m_mut)
    {
        LOCK(m_mut);
    }
};
X g_x;

void caller() EXCLUSIVE_LOCKS_REQUIRED(!g_mutex)
{
    f1();
    g_x.f1();
}

Yes, it has to be propagated, but I wouldn't call it a "problem" though because it works exactly as intended. True that it creates inconvenience with code isolation (like this code should not know about that mutex), but after all a global mutex is not isolated, so IMO it is ok and even desirable to propagate its negative annotation.