Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

doc: in Go memory model "threads" should read "goroutines" #28306

Closed
YoshikiShibata opened this issue Oct 22, 2018 · 4 comments
Closed

doc: in Go memory model "threads" should read "goroutines" #28306

YoshikiShibata opened this issue Oct 22, 2018 · 4 comments
Labels
Documentation FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Unplanned

Comments

@YoshikiShibata
Copy link

doc/go_mem.html uses threads instead of goroutines in two places. I think they should read "goroutines"

diff --git a/doc/go_mem.html b/doc/go_mem.html
index 143f3b2ff2..c1ec9e3c47 100644
--- a/doc/go_mem.html
+++ b/doc/go_mem.html
@@ -385,7 +385,7 @@ before call <i>n</i>+1 to <code>l.Lock</code>.
 The <code>sync</code> package provides a safe mechanism for
 initialization in the presence of multiple goroutines
 through the use of the <code>Once</code> type.
-Multiple threads can execute <code>once.Do(f)</code> for a particular <code>f</code>,
+Multiple goroutines can execute <code>once.Do(f)</code> for a particular <code>f</code>,
 but only one will run <code>f()</code>, and the other calls block
 until <code>f()</code> has returned.
 </p>
@@ -525,7 +525,7 @@ implies observing the write to <code>a</code>, so this program could
 print an empty string too.
 Worse, there is no guarantee that the write to <code>done</code> will ever
 be observed by <code>main</code>, since there are no synchronization
-events between the two threads.  The loop in <code>main</code> is not
+events between the two goroutines.  The loop in <code>main</code> is not
 guaranteed to finish.
 </p>
@agnivade
Copy link
Contributor

/cc @robpike

@robpike
Copy link
Contributor

robpike commented Oct 22, 2018

Not sure about this, but it's really Russ's document. "Threads" may be the right term here. /cc @rsc

@bcmills
Copy link
Contributor

bcmills commented Oct 23, 2018

See also #27808 (another clarification in that section).

@bcmills bcmills added Documentation NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Oct 23, 2018
@bcmills bcmills added this to the Go1.12 milestone Oct 23, 2018
@ianlancetaylor ianlancetaylor changed the title doc/go_mem.html: "threads" should read "goroutines" doc: in Go memory model "threads" should read "goroutines" Dec 11, 2018
@ianlancetaylor ianlancetaylor modified the milestones: Go1.12, Unplanned Dec 11, 2018
@YoshikiShibata
Copy link
Author

After considering scheduling multiple coroutines on a OS thread, I think the memory model documentation is correct. So I think this issue should be closed.

@robpike robpike closed this as completed Jul 3, 2020
@golang golang locked and limited conversation to collaborators Jul 3, 2021
@rsc rsc removed their assignment Jun 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
Documentation FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
7 participants
@rsc @YoshikiShibata @agnivade @ianlancetaylor @robpike @bcmills @gopherbot