aboutsummaryrefslogtreecommitdiff
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
commit2dbe352b0f34189045800bc3857a3c0b300c6f42 (patch)
tree656be546565621c29df934739f0813abbd7c7aa2
parentdd58096ae60e55bf064f10b5ff0f7fd92e5b1251 (diff)
downloadgo-2dbe352b0f34189045800bc3857a3c0b300c6f42.tar.gz
go-2dbe352b0f34189045800bc3857a3c0b300c6f42.zip
[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 #6242. LGTM=dan.kortschak, r, rsc R=golang-codereviews, 0xjnml, dan.kortschak, r, rsc CC=golang-codereviews https://golang.org/cl/101980047 »»» LGTM=iant R=golang-codereviews, iant CC=golang-codereviews, r https://golang.org/cl/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 69e7c8ce75..2ea1ded7a3 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>