Go learning notes on _routine and channel

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

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:

• Defines a function functionnamethat can be used when calling asynchronously go functionName .

• Using an anonymous function, the go func(参数列表){函数执行体}() last function is to () let the function execute.

The following simple code deepens:

 /////////the first sample 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  f UNC  () {fmt. Println ( "Hello World" )} () //Don't forget it here () }
     

Now in terms of the go keyword function, once the go is placed before the function, it means assigning a sub- routine to let the function play (a little self-extinguishing feeling), while the main routine Why do you keep doing that? 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 the int type, then The channel type ischan int

• Use make to create a channel, such as no cache ci := make(chan int) , to specify the 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.

• Channel passes <- to receive and send data. For example channel <- value , it is obvious that value values are sent to channel channels; value := <- ch note the arrows that read the data from the channel channels to the VALUE, or can be said to receive data from the channel channels assigned to value. By the way <- channel , it is obvious that the data is read from the channel, but it is not assigned to any one variable, so it 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.

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

4. Then write the data to the channel, channel_c <- value because there is no allocation of the cache, so it will be blocked, in other words, the card is here, can wait, waiting for the program to read from the 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. )

6. 2015.04.22---to the above analogy modified. PS: The above analogy is not very appropriate, I think it is possible to think so, channel is connected to two routine channels, when the sender of the channel to send data, but delay to wait for the receiver, But the idea of conscientious, always waiting in that position, that is, channel_c <- value the sending statement, until the receiver receives the channel data, can proceed to the next statement. 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 recipients, 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 that the cache is full, you can only wait, Until someone comes to fetch the data and frees up the cache space, the data can be written.

8. Now instead of reading the data from the channel, v := <- channel_c there are two cases: when there is data in the Channel_c channel, it will certainly not clog up, read it smoothly, and when the Channel_c channel has no data, it is naturally blocked. Unless the program writes data to the channel somewhere else!

9. The

10. Finally tells about the channel that was allocated the cache, for example: channel: = Make (chan int,2) . If you write the data to the channel at this time channel <-2 , because the cache is allocated, it means that I can write directly, not blocked, but this is only when my cache is not full of the situation will not block. It is no problem to write a channel <-3 to the channel below. 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!