runtime: fix comment
IRIW requires 4 threads: first writes x, second writes y,
third reads x and y, fourth reads y and x.
This is Peterson/Dekker mutual exclusion algorithm based on
critical store-load sequences:
http://en.wikipedia.org/wiki/Dekker's_algorithm
http://en.wikipedia.org/wiki/Peterson%27s_algorithm
Change-Id: I30a00865afbe895f7617feed4559018f81ff4528
Reviewed-on: https://go-review.googlesource.com/7561
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Rick Hudson <rlh@golang.org>
diff --git a/src/runtime/mbarrier.go b/src/runtime/mbarrier.go
index f6e9269..1f9bd95 100644
--- a/src/runtime/mbarrier.go
+++ b/src/runtime/mbarrier.go
@@ -53,11 +53,13 @@
//
// ld r1, [slotmark] ld r2, [slot]
//
-// This is a classic example of independent reads of independent writes,
-// aka IRIW. The question is if r1==r2==0 is allowed and for most HW the
-// answer is yes without inserting a memory barriers between the st and the ld.
-// These barriers are expensive so we have decided that we will
-// always grey the ptr object regardless of the slot's color.
+// Without an expensive memory barrier between the st and the ld, the final
+// result on most HW (including 386/amd64) can be r1==r2==0. This is a classic
+// example of what can happen when loads are allowed to be reordered with older
+// stores (avoiding such reorderings lies at the heart of the classic
+// Peterson/Dekker algorithms for mutual exclusion). Rather than require memory
+// barriers, which will slow down both the mutator and the GC, we always grey
+// the ptr object regardless of the slot's color.
//go:nowritebarrier
func gcmarkwb_m(slot *uintptr, ptr uintptr) {
switch gcphase {
