diff options
author | Russ Cox <rsc@golang.org> | 2014-06-06 22:07:11 -0400 |
---|---|---|
committer | Russ Cox <rsc@golang.org> | 2014-06-06 22:07:11 -0400 |
commit | 2dbe352b0f34189045800bc3857a3c0b300c6f42 (patch) | |
tree | 656be546565621c29df934739f0813abbd7c7aa2 | |
parent | dd58096ae60e55bf064f10b5ff0f7fd92e5b1251 (diff) | |
download | go-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.html | 10 |
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> |