Mutex/thread sanity analysis

[sim642]

While debugging some benchmark programs, I noticed they themselves contain silly bugs:

1. Forgetting to unlock a mutex (e.g. at early return), which makes any following call of the function deadlock or undefined behavior: https://github.com/goblint/bench/blob/16ee6e2dfa54881be2161cb5bb6eee8cce5736d7/pthread/pfscan_comb.c#L1234-L1237.
2. Unlocking a mutex, which isn't held, which is undefined behavior, e.g. forgetting to relock at the end of a loop for protected condition check: https://github.com/goblint/bench/blob/16ee6e2dfa54881be2161cb5bb6eee8cce5736d7/pthread/smtprc_comb.c#L2379-L2386. MayLock Analysis & Sanity Checks of Mutex Usage & Analysis of Mutex Types #839
3. Re-initializing a locked mutex.

At least in the case of non-recursive mutexes, these issues and other similar ones might be useful to have some simple analysis for to warn about.

[sim642]

A related point that arose during GobCon is that joining a thread multiple times is also undefined behavior.

[michael-schwarz]

Other instances Helmut and I identified as easy wins to claim we are fully-fledged analyzer of concurrency bugs:

• Mutexes being used before being initialized (or after being destroyed)
  • Warn when dynamically allocated mutex escapes before being initialized
  • Warn if pthread_mutex_destroy is called while other thread that use it may still be running or it is used in the thread that called destroy after it was destroyed.
• Returning from a thread while holding a mutex (more likely to be a bug than just returning from a function while holding a mutex) MayLock Analysis & Sanity Checks of Mutex Usage & Analysis of Mutex Types #839
• Calling pthread_cond_wait with a mutex that is not held MayLock Analysis & Sanity Checks of Mutex Usage & Analysis of Mutex Types #839

[michael-schwarz]

Related #1100