Added some example tooling discussion.

This commit is contained in:
Titus Winters 2016-11-03 12:09:26 -04:00
parent 7476fc3194
commit e8ecae3171

View File

@ -11635,16 +11635,40 @@ this can be a security risk.
##### Enforcement
Some is possible, do at least something.
There are commercial and open-source tools that try to address this problem, but static tools often have many false positives and run-time tools often have a significant cost.
We hope for better tools.
When possible, rely on tooling enforcement, but be aware that any tooling
solution has costs and blind spots. Defense in depth (multiple tools, multiple
approaches) is particularly valuable here.
Help the tools:
In the realm of static enforcement,
both [clang](http://clang.llvm.org/docs/ThreadSafetyAnalysis.html) and some
older verisons of [gcc](https://gcc.gnu.org/wiki/ThreadSafetyAnnotation) have
some support for static annotation of thread safety properties. Consistent use
of this technique turns many classes of thread-safety errors into compile-time
errors. The annotations are generally local (marking a particular member
variable as guarded by a particular mutex), and are usually easy to
learn. However, as with many static tools, it can often present false
negatives - cases that should have been caught but were allowed.
* less global data
* fewer `static` variables
* more use of stack memory (and don't pass pointers around too much)
* more immutable data (literals, `constexpr`, and `const`)
Clang's [Thread Sanitizer](http://clang.llvm.org/docs/ThreadSanitizer.html) (aka
tsan) is a powerful example of dynamic tools: it changes the build and execution
of your program to add bookkeeping on memory access, absolutely identifying data
races in a given execution of your binary. The cost for this is both memory
(5-10x in most cases) and CPU slowdown (2-20x). Dynamic tools like this are best
when applied to integration tests, canary pushes, or unittests that operate on
multiple threads. Workload matters: When tsan identifies a problem, it is
effectively always an actual data race, but it can only identify races seen in a
given execution.
There are many other tools, both commercial and open-source. Thread safety is
challenging, often getting the better of experienced programmers: tooling is an
important strategy to mitigate those risks.
There are other ways you can mitigate the chance of data races:
* Avoid global data
* Avoid `static` variables
* More use of value types on the stack (and don't pass pointers around too much)
* More use of immutable data (literals, `constexpr`, and `const`)
### <a name="Rconc-data"></a>CP.3: Minimize explicit sharing of writable data