From: Dmitry Vyukov Date: Fri, 13 Mar 2015 13:02:47 +0000 (+0300) Subject: runtime: fix comment X-Git-Tag: go1.5beta1~1540 X-Git-Url: http://www.git.cypherpunks.su/?a=commitdiff_plain;h=2e7f0a00c337c0a536fafc1d5cb831cb4c76efad;p=gostls13.git 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 Reviewed-by: Rick Hudson --- diff --git a/src/runtime/mbarrier.go b/src/runtime/mbarrier.go index f6e9269858..1f9bd95cae 100644 --- a/src/runtime/mbarrier.go +++ b/src/runtime/mbarrier.go @@ -53,11 +53,13 @@ import "unsafe" // // 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 {