Bump LLVM to new radsan sanitizer - Improve readme with new version o…

…f this (#19)

* Bump LLVM, fix readme

* Swap contested->contended

README.md

@@ -224,30 +224,30 @@ The default configuration is `RADSAN_ERROR_MODE=exit`.
 
 You might find a case where you disagree with RADSan's assessment of real-time
 safety. Consider the case of locking and unlocking a mutex; these operations
-can block if the mutex is contested, and common advice is to avoid them in
+can block if the mutex is contended, and common advice is to avoid them in
 real-time contexts. However, it can be argued that their use is safe under
-certain special constraints, like if the mutex is never contested (you might be
+certain special constraints, like if the mutex is never contended (you might be
 re-using multi-threaded code in a single-threaded context), or if it's only
-contested at times when a user is expecting a glitch anyway (if, say, an audio
+contended at times when a user is expecting a glitch anyway (if, say, an audio
 device is disconnected). RADSan always assumes the worst, and this may not be
-true for your particular use case. You can turn off RADSan's error detection
-temporarily by wrapping code in `radsan_off()` and `radsan_on()` as follows:
+true for your particular use case. 
+
+You can turn off RADSan's error detection for such a call by extracting the 
+behavior to a function, and adding adding the `no_sanitize` attribute:
+
 
 ```cpp
-#include "radsan.h" // (found in llvm-project/compiler-rt/lib/radsan)
-// or:
-// extern "C" {
-//   void radsan_off();
-//   void radsan_on();
-// }
+__attribute__((no_sanitize("realtime")))
+void mutex_unlock_uncontended (std::mutex& m)
+{
+    m.unlock();
+}
 
 [[clang::realtime]] float process (float x)
 {
-    auto const y = 2.0f * x;
-
-    radsan_off();
-    i_know_this_method_is_realtime_safe_but_radsan_complains_about_it();
-    radsan_on();
+    ...
+    mutex_unlock_uncontended(m); // I know this is always uncontended, thus real-time safe!
+    ...
 }
 ```