From e6597e12bc40a28ed4c682e71f7159b9cb2403e7 Mon Sep 17 00:00:00 2001 From: Jon Gjengset Date: Fri, 7 Apr 2017 09:13:06 -0400 Subject: [PATCH] Mention interrupts and green threads --- src/doc/unstable-book/src/compiler-barriers.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/doc/unstable-book/src/compiler-barriers.md b/src/doc/unstable-book/src/compiler-barriers.md index df0e20eefadb..9e137a5c4f87 100644 --- a/src/doc/unstable-book/src/compiler-barriers.md +++ b/src/doc/unstable-book/src/compiler-barriers.md @@ -32,7 +32,12 @@ racing *with itself*. That is, if a given thread is executing one piece of code, and is then interrupted, and starts executing code elsewhere (while still in the same thread, and conceptually still on the same core). In traditional programs, this can only occur when a signal -handler is registered. Consider the following code: +handler is registered. In more low-level code, such situations can also +arise when handling interrupts, when implementing green threads with +pre-emption, etc. + +To give a straightforward example of when a `compiler_barrier` is +necessary, consider the following example: ```rust # use std::sync::atomic::{AtomicBool, AtomicUsize};