summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRuss Cox <rsc@golang.org>2014-06-06 22:07:11 -0400
committerRuss Cox <rsc@golang.org>2014-06-06 22:07:11 -0400
commit2c5f04476cffe74be3cb8b9c6882b53446ea6479 (patch)
tree19dcdfbf71564a68f543558b8f7b918c1c37e88c
parent81d77633506982abc3dcb6dd21734676fa2f3bff (diff)
downloadgo-2c5f04476cffe74be3cb8b9c6882b53446ea6479.tar.gz
[release-branch.go1.3] doc: fix happens-before rules for buffered channels
??? CL 101980047 / 12c9a9ff50d8 doc: fix happens-before rules for buffered channels The current wording is reversed in 2 places. Not sure how it got 4 LGTMs (mine was there as well). Update issue 6242. LGTM=dan.kortschak, r, rsc R=golang-codereviews, 0xjnml, dan.kortschak, r, rsc CC=golang-codereviews https://codereview.appspot.com/101980047 ??? LGTM=iant R=golang-codereviews, iant CC=golang-codereviews, r https://codereview.appspot.com/106830047
-rw-r--r--doc/go_mem.html10
1 files changed, 5 insertions, 5 deletions
diff --git a/doc/go_mem.html b/doc/go_mem.html
index 69e7c8ce7..2ea1ded7a 100644
--- a/doc/go_mem.html
+++ b/doc/go_mem.html
@@ -1,6 +1,6 @@
<!--{
"Title": "The Go Memory Model",
- "Subtitle": "Version of March 6, 2012",
+ "Subtitle": "Version of May 31, 2014",
"Path": "/ref/mem"
}-->
@@ -275,17 +275,17 @@ crash, or do something else.)
</p>
<p class="rule">
-The <i>k</i>th send on a channel with capacity <i>C</i> happens before the <i>k</i>+<i>C</i>th receive from that channel completes.
+The <i>k</i>th receive on a channel with capacity <i>C</i> happens before the <i>k</i>+<i>C</i>th send from that channel completes.
</p>
<p>
This rule generalizes the previous rule to buffered channels.
It allows a counting semaphore to be modeled by a buffered channel:
-the number of items in the channel corresponds to the semaphore count,
-the capacity of the channel corresponds to the semaphore maximum,
+the number of items in the channel corresponds to the number of active uses,
+the capacity of the channel corresponds to the maximum number of simultaneous uses,
sending an item acquires the semaphore, and receiving an item releases
the semaphore.
-This is a common idiom for rate-limiting work.
+This is a common idiom for limiting concurrency.
</p>
<p>