Finding threading bugs

Question

Is there any point trying to find threading problems at compile time?

I'm talking about data races, deadlocks, corrupted state etc...

Answer 1

You might want to take a look at http://software.intel.com/en-us/articles/debugging-threaded-applications/, for example. There is software dedicated to this task, like http://software.intel.com/en-us/intel-thread-checker/.

EDIT: Sorry, didn't see that you asked for a compile-time solution. Maybe this answer is still of relevance.

Answer 2

While I do not know of any compiler with explicit thread-safety diagnosis options, Coverity is static analysis tool which does provide checkers for concurrency issues, which by not being done at runtime could be loosely comparable to "compile time", since the compiler is a tool that before generating code does some static analysis for validity of the come, and that seems to be what your are looking for, not necessarily tied to compile time, ie before generating code...

If the static analysis tool understands the concurrency primitives then yes it is possible to do static analysis for threading problems. Whether a tool/compiler is at the point where those issues are correctly pointed out I have still to experience.

NB: At work we have used Coverity to do static analysis, but while we wade through all the "issues" pointed by the tool we have not yet enabled the concurrency checker so I cannot give any testimonial of how well it works. As for the other more common checkers, they pointed out a bunch of valid issues, as well as some innocuous issues, and a few false positives. I hope to check the output of the concurrency checker soon to judge myself its usefulness.

Answer 3

While this isn't compile time, you might want to check out Helgrind:

Overview

Helgrind is a Valgrind tool for detecting synchronisation errors in C, C++ and Fortran programs that use the POSIX pthreads threading primitives.

The main abstractions in POSIX pthreads are: a set of threads sharing a common address space, thread creation, thread joining, thread exit, mutexes (locks), condition variables (inter-thread event notifications), reader-writer locks, spinlocks, semaphores and barriers.

Helgrind can detect three classes of errors, which are discussed in detail in the next three sections:

1. Misuses of the POSIX pthreads API.
2. Potential deadlocks arising from lock ordering problems.
3. Data races -- accessing memory without adequate locking or synchronisation.

Problems like these often result in unreproducible, timing-dependent crashes, deadlocks and other misbehaviour, and can be difficult to find by other means.

Helgrind is aware of all the pthread abstractions and tracks their effects as accurately as it can. On x86 and amd64 platforms, it understands and partially handles implicit locking arising from the use of the LOCK instruction prefix.

Helgrind works best when your application uses only the POSIX pthreads API. However, if you want to use custom threading primitives, you can describe their behaviour to Helgrind using the ANNOTATE_* macros defined in helgrind.h. This functionality was added in release 3.5.0 of Valgrind, and is considered experimental.

Since Boost.Threads is based on POSIX pthreads ( at least on Linux ) I would guess that it would work for it as well.