Go learning notes _routine and Channel

This is a creation in Article, where the information may have evolved or changed.

Article Source: http://www.itnose.net

Go language Concurrent programming

Evening time to learn the next Go language concurrent programming, from the Goroutine to the channel mechanism, from the beginning of the hazy to the moment the clouds to see the feeling of the sun, the process of learning is always exciting! Of course, the current understanding is not thorough enough. The next article will take an example to analyze.

Goroutine

Similar to the opening process, threading practices, the Go language is used for goroutine. The usage is extremely simple, that is, using the GO keyword, there are two ways to use it:

• Define a function functionname to use the statement go functionname when calling asynchronously.

• Using an anonymous function, the usage is the Go func (argument list) {function execution body} (), stating that the last () function is to let the function execute.

The following simple code deepens:

    The first example code:///////////    func SayHello (name string) {        FMT. Println ("Hello" +name)    }    //Main program Entry    func main () {        go SayHello ("Pmst")    }    /////////The second example code://    //Main program Entry    func main () {        go func () {            fmt. Println ("Hello World")        } ()     //Don't forget the ()    }

Now in terms of the GO keyword, once the go is placed before the function, it means assigning a sub-routine to let the function play (a bit of self-extinguishing), while the main routine continues to do what. For example, there's a bunch of data on hand that need to go through super-complex, time-consuming calculations to get answers. Obviously our Lord routine is unlikely to do just that, and it has other things to deal with. So we open up a routine to make it count.

So the question is, does this really solve the problem that the main routine is not locked, and can complete the time-consuming calculation, but after calculating the answer, how to return to the main routine use it?

This is the use of the channel below.

Channel

How is data communicated between the Goroutine? The following two types:

1. Shared memory memory space.

2. The Go language recommended communication mechanism channel.

Here is my understanding of the channel:

• Goroutine use the channel to receive or send values, and these values can only be specific types, specified by themselves, such as two routine between the value of int type, then the channel type is chan int

• Create channel via make, for example no cache CI: = make (chan int), specify cache CIB: = Make (chan int,2). It is obvious that the difference is in the following statement, which indicates that the channel is classified as 2 cache space, as for the difference, as shown below.

• The channel receives and sends data through <-. The channel <-value, for example, is clearly the value that is being sent to the tunnel channels; values: = <-ch, note the arrows, which indicate that the data is read from channel channels to value, or can be said to be received from channel channels The data is assigned to value. By the way, and other <-channel, apparently also read data from the channel, but not assigned to any one variable, so that means discard!

On the issue of channel congestion, I think it is necessary to focus on carding. Take a look at the summary below

First, the channel receives and sends are blocked, unless the corresponding end is ready. It's best to say, for example.

1. Create a new channel, Channel_c: = make (chan int), note that the cache is not allocated.

2. Then writes data to the channel, Channel_c <-value, because there is no cache allocated, so this is blocked, in other words, stuck here, waiting, waiting for the program to read data from that channel somewhere! PS: Just like a very short tube, a data is plugged into it, it will be leaking out, so I have been hand "hold" data, do not do the following things. It is only when the receiving towners takes the data that he can spare his hand to do anything else.

3. 2015.04.22---The above analogy is modified. PS: The above analogy is not very appropriate, I think it is possible to think that the channel is connected to two routine channels, when the sender to the channel to send data, but slow to wait for the receiver, but the idea of conscientious, always waiting in that position, that is Channel_c: Make (chan int) This sends the statement until the receiver receives the channel data before the next statement can be made. So if there is a cache is different, like a post, take the data to the channel this send "mail", although there may be no recipient, but I can temporarily put in the "post" (cache) here, and then continue to do their own work, and so the next time to send data to the channel found the cache full, you can only wait, unless Someone comes to fetch the data and frees up the cache space before the data can be written. The

4. is now replaced with the read data from the Channel, V: = <-Channel_c, in two cases: when there is data in the Channel_c channel, it is certainly not blocked, read it smoothly, and when the Channel_c channel has no data, Then nature is blocked, unless the program writes data to the channel somewhere else!

5. Finally tells about the channel that was allocated the cache, for example: Channel: = Make (chan int,2). If the channel <-2 is written to the channels, because the cache is allocated, it means that I can write directly and not clog it, but only if my buffer is not full. It is no problem to write a channel <-3 below toward the tunnel. But the cache is filled! If you write again at this time will be blocked, only the program somewhere from the channel to read the data to make room, you can write!

Article Source: http://www.itnose.net/st/6252785.html