…arameter instead

…ized, otherwise the ft library leaks memory.

…-timeout-2

…function

…can be used

…ractal tree tests. Unfortunately, not all of these warnings can be immediately addressed. The suppression file allows some of these issues to be suppressed. There are two reasons for suppressing thread sanitizer issues. First, there are a couple of issues that dominate the warnings and cause other less frequent issues to be lost like a needle in a haystack. The adjustment of row counts, for example, occurs frequently. Second, some of the issues are not bugs but result from algorithm design. For example, the lock order inversion issue in the locktree's concurrent tree occur when the tree is rebalanced and the mutex order from root to leaf in the tree is changed. Since there is not way (that I know) to inform the thread sanitizer that this is to be expected, we need to suppress this issue instead.

Valgrind was used as a race detector on the fractal tree software before the thread sanitizer existed.  Its helgrind and drd tools allow one to annotate address regions in which data races should be ignored.  The fractal tree software is littered with helgrind annotations.  The thread sanitizer does not have a similar facility.  However, issues identified by the thread sanitizer can be suppressed by code location, either by function or by file.  We can use the suppression facility to suppress data race reporting on variables in particular functions.  If these functions are sufficiently small, then we can be confident that we are suppressing races on specific variables.

Many data races identified by the thread sanitizer can be fixed by replacing standard C+ variables with C++ atomic variables.  This replacement will remove the need for thread sanitizer suppressions.