> Channel Communication The first part describes the most intuitive sequential relationship between send and receive operations:> * Send data to a Channel before receiving data. * As a result, we are able to control the order of operations distributed in two Goroutine. "' Govar v intvar WG sync. Waitgroupwg.add (2) ch: = make (chan int) go func () {v = 1 ch <-1 WG. Done ()} () go func () {<-ch fmt. Println (v) WG. Done ()} () WG. Wait () "(for clarity, the definition of the main function and the import statement are omitted) the order of operations is as follows (*x*→*y* represents *x* occurring before *y*): ' v = 1 ' → ' ch <-1 ' → ' <-ch ' → ' fmt. Println (v) ' In addition to the above, there are more order rules, this article will focus on Channel. # # Send to receive! [Image] (https://raw.githubusercontent.com/studygolang/gctt-images/master/sync-goroutine/part2-1.jpeg) In addition to the above rules, There is also a rule to supplement it, this rule says that the receive occurs before sending is complete: send start → receive → send end ' Govar V, w intvar WG sync. Waitgroupwg.add (2) ch: = make (chan int) go func () {v = 1 ch <-1 FMT. PRINTLN (W) WG. Done ()} () go func () {w = 2 <-ch fmt. Println (v) WG. Done ()} () WG. Wait () ' ' because with this new rule, more operations are in order: ' W = 2 ' → ' <-ch ' → send operation ' ch <-1 ' end → ' fmt. Println (W) ' by ensuring that the assignment has been completed, we can resolve the initial problem with the display variable ' V '. "' Gogo func () {v = 1 <-ch WG. Done ()} () go func () {ch <-1 fmt. Println (v) WG. Done ()} () "Now the second GoroutINE will send data to the channel, which needs to wait for the assignment in the first goroutine ' V = 1 ' to complete. The send operation cannot be completed until the corresponding receive operation. ' V = 1 ' → ' <-ch ' → ' ch <-1 ' end → ' fmt. Println (v) ' # # Close channel! [Image] (Https://raw.githubusercontent.com/studygolang/gctt-images/master/sync-goroutine/part2-2.jpeg) When the channel is closed, The receive operation immediately returns the [0 value] (https://golang.org/ref/spec#The_zero_value) of the data type in the channel. "' Goch: = make (chan int) close (CH) fmt. PRINTLN (<-ch)//Prints 0 ">* close channel occurs before receiving 0 value from the closed channel * Replace the send operation with the call of the self-contained function *close* can also solve our initial problem. "' Gogo func () {v = 1 close (CH) WG. Done ()} () go func () {<-ch fmt. Println (v) WG. The order of the operations of Done ()} () is: ' V = 1 ' → ' Close (ch) ' → ' <-ch ' → ' fmt. Println (v) ' # # has a cached channel so far we have discussed the channel without caching. A cached channel is not blocked when the cache is not full, and the receive operation does not block when the cache is not empty: "' Goch: = make (chan int, 1) ch <-1fmt. Println (<-ch) "The above procedure does not end in deadlock, although the recipient is not ready to send. For a cached channel, all the rules mentioned so far have been established, except that the receive occurred before the end of the send. The reason is simple, (when the cache is not full), there is no need to prepare the recipient, the send operation can be completed. >* for a channel with a capacity of C, the K-receive occurs before the sending of (K+C) is complete. * Assume that the cache capacity is set to 3. The first 3 operations that send data to the channel can be returned even without a corresponding receive statement. But toThe 4th send operation completes and must have at least one receive operation completed. "' Govar v intvar WG sync. Waitgroupwg.add (2) ch: = Make (chan int, 3) go func () {v = 1 <-ch WG. Done ()} () go func () {ch <-1 ch <-1 ch <-1 ch <-1 FMT. Println (v) WG. Done ()} () WG. Wait () "This small section uses the cached channel to solve our initial problem." ---likes to help people find this article. If you want to get updates on new articles, please follow me. # # Resources-[Goroutine Synchronization (first part)] (HTTPS://MEDIUM.COM/GOLANGSPEC/SYNCHRONIZED-GOROUTINES-PART-I-4FBCDD64A4EC) > Suppose that Go program starts the goroutines:> medium.com-[Go memory model--go programming language] (HTTPS://GOLANG.ORG/REF/MEM) >the go Memory model specifies the conditions under which reads of a variable in one goroutine can be guaranteed to...> GOLANG.O rg-[Go Language Specification--go programming language] (HTTPS://GOLANG.ORG/REF/SPEC) >go is a general-purpose language designed with systems Programmin G in mind. It is strongly typed and garbage-collected...> golang.org*[reserved Partial copyright] (http://creativecommons.org/licenses/by/4.0/) **[ Golang] (https://medium.com/tag/golang?source=post) **[programming] (Https://medium.com/tag/programming?source=poST) **[concurrency] (https://medium.com/tag/concurrency?source=post) **[channels] (Https://medium.com/tag/channel? Source=post) **[synchronization] (https://medium.com/tag/synchronization?source=post) * * * do you like to read? Give Michałłowicki some applause. * * Simply encourage or shout, depending on how much you like the article to applaud it.
via:https://medium.com/golangspec/synchronized-goroutines-part-ii-b1130c815c9d
Author: Michałłowicki Translator: Krystollia proofreading: polaris1119
This article by GCTT original compilation, go language Chinese network honor launches
This article was originally translated by GCTT and the Go Language Chinese network. Also want to join the ranks of translators, for open source to do some of their own contribution? Welcome to join Gctt!
Translation work and translations are published only for the purpose of learning and communication, translation work in accordance with the provisions of the CC-BY-NC-SA agreement, if our work has violated your interests, please contact us promptly.
Welcome to the CC-BY-NC-SA agreement, please mark and keep the original/translation link and author/translator information in the text.
The article only represents the author's knowledge and views, if there are different points of view, please line up downstairs to spit groove
101 Reads
