From c707d8385639dfda22dc06b112f5f7af78006a1f Mon Sep 17 00:00:00 2001 From: Austin Clements Date: Mon, 18 Apr 2016 18:28:36 -0400 Subject: [PATCH] runtime: fix typos in comment about gcscanvalid Change-Id: Id4ad7ebf88a21eba2bc5714b96570ed5cfaed757 Reviewed-on: https://go-review.googlesource.com/22210 Reviewed-by: Ian Lance Taylor Run-TryBot: Austin Clements TryBot-Result: Gobot Gobot --- src/runtime/proc.go | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/runtime/proc.go b/src/runtime/proc.go index 9c840882b6..d5acbee0a7 100644 --- a/src/runtime/proc.go +++ b/src/runtime/proc.go @@ -643,17 +643,17 @@ func readgstatus(gp *g) uint32 { return atomic.Load(&gp.atomicstatus) } -// Ownership of gscanvalid: +// Ownership of gcscanvalid: // // If gp is running (meaning status == _Grunning or _Grunning|_Gscan), -// then gp owns gp.gscanvalid, and other goroutines must not modify it. +// then gp owns gp.gcscanvalid, and other goroutines must not modify it. // // Otherwise, a second goroutine can lock the scan state by setting _Gscan -// in the status bit and then modify gscanvalid, and then unlock the scan state. +// in the status bit and then modify gcscanvalid, and then unlock the scan state. // // Note that the first condition implies an exception to the second: // if a second goroutine changes gp's status to _Grunning|_Gscan, -// that second goroutine still does not have the right to modify gscanvalid. +// that second goroutine still does not have the right to modify gcscanvalid. // The Gscanstatuses are acting like locks and this releases them. // If it proves to be a performance hit we should be able to make these -- 2.48.1