diff --git a/CppCoreGuidelines.md b/CppCoreGuidelines.md
index 6b6ee80..db9d232 100644
--- a/CppCoreGuidelines.md
+++ b/CppCoreGuidelines.md
@@ -7324,9 +7324,9 @@ But heed the warning: [Avoid "naked" `union`s](#Ru-naked)
##### Example
// Short string optimization
-
+
constexpr size_t buffer_size = 16; // Slightly larger than the size of a pointer
-
+
class Immutable_string {
public:
Immutable_string(const char* str) :
@@ -7339,18 +7339,18 @@ But heed the warning: [Avoid "naked" `union`s](#Ru-naked)
strcpy_s(string_ptr, size + 1, str);
}
}
-
+
~Immutable_string()
{
if (size >= buffer_size)
delete string_ptr;
}
-
+
const char* get_str() const
{
return (size < buffer_size) ? string_buffer : string_ptr;
}
-
+
private:
// If the string is short enough, we store the string itself
// instead of a pointer to the string.
@@ -7358,7 +7358,7 @@ But heed the warning: [Avoid "naked" `union`s](#Ru-naked)
char* string_ptr;
char string_buffer[buffer_size];
};
-
+
const size_t size;
};
@@ -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`)
### CP.3: Minimize explicit sharing of writable data
@@ -12647,7 +12671,7 @@ Example with thread-safe static local variables of C++11.
static My_class my_object; // Constructor called only once
// ...
}
-
+
class My_class
{
public:
@@ -12670,7 +12694,7 @@ Double-checked locking is easy to mess up. If you really need to write your own
##### Example, bad
-Even if the following example works correctly on most hardware platforms, it is not guaranteed to work by the C++ standard. The x_init.load(memory_order_relaxed) call may see a value from outside of the lock guard.
+Even if the following example works correctly on most hardware platforms, it is not guaranteed to work by the C++ standard. The x_init.load(memory_order_relaxed) call may see a value from outside of the lock guard.
atomic x_init;
@@ -12687,12 +12711,12 @@ Even if the following example works correctly on most hardware platforms, it is
One of the conventional patterns is below.
std::atomic state;
-
+
// If state == SOME_ACTION_NEEDED maybe an action is needed, maybe not, we need to
// check again in a lock. However, if state != SOME_ACTION_NEEDED, then we can be
// sure that an action is not needed. This is the basic assumption of double-checked
// locking.
-
+
if (state == SOME_ACTION_NEEDED)
{
std::lock_guard lock(mutex);