Introduction
Concurrency essentially makes a go program run faster by improving the response time and improving the resource utilization. Goroutines and channels are the programming constructs used in go achieve concurrency, goroutines are cheap, lightweight threads whereas channels let goroutines talk to each other.
while writing looping code you tell your computer to execute a few line of codes again and again, whereas while writing concurrent code you tell your computer to bring his friend, another computer , to execute this other piece of code while your computer keeps on doing his work. Goroutine is that other computer except that it's not a computer and well guess what it's not a thread either. One another thing to note here is that the other computer is running independently from your computer. If they wanted to talk to each other they would have to use something called a channel in go. Let us now see the nuances of goroutine and channel
goroutines
The word "go" needs to be appended to any named or anonymous function and that function becomes the goroutine. simple demonstration below
func printhi() { fmt.Println("hi")}
func main() {
// named function
go printhi()
// Anonymous function
go printHello() { fmt.Prinln("Hello")}()
}
Here printhi and printHello are supposed to run at the same time, while the main function is also running. If executed there's a high chance neither hi nor Hello is printed on the stdout because the program runs only till the main function is running i.e. here main doesn't wait for goroutines to end and simply ends.
Features of goroutines
- They are lightweight and cheap , in comparison to threads
- Thousands of independent goroutines can be multiplexed onto a single thread
- Named or Anonymous functions can be made to run as goroutines
- If a single thread is blocked, the other goroutines on the thread are moved onto another unblocked thread, by the go runtime.
channel
Channels can be visualized as a box, now if it's a unbuffered channel then it will only hold a single item, meaning if A goroutine puts 1 inside the box, goroutine B can not put anything inside it until the existing 1 is taken out of the box, this causes blocking. Unbuffered channels on the other hand can hold items until they're full, blocking for unbuffered channels occurs when either it's full or empty.
Getting used to the blocking mechanism is a lil bit tricky for beginners, in simpler terms the program sleeps and waits for something to wake it up.That something can be another goroutine or main function.
Let us see in which cases blocking of program occurs ,we will take 2 goroutines ( send and receive ) and 1 channel (ch)
- ch contains 1 inside it and send wants to put 2 inside ch, it will cause a block
- ch is empty and receive wants values from ch , it will cause a block
A rookie mistake would be to just simply send and receive data from the channel from the main program. what happens is one of them causes blocking and since we don't have any other goroutine besides the main function running, nothing unblocks the main program itself and hence *DEADLOCK * occurs.
Let us know, see the code for creating a channel and sending, receiving values from it
// channel is created using "make"
// this here is a unbuffered integer channel
// int can be replaced by bool, string or anything that the user wants.
ch := make(chan int)
// this here is a buffered integer channel of size 2
ch := make(chan int , 2 )
// this is how you can insert a value inside a channel
ch <- 1
// this is how you can take values out of a channel
number := <- ch
// The direction of arrow indicates the flow of data.
The buffered channels are channels of a fixed size, items can be added until all the space gets occupied inside a channel and in the same way, items can be retrieved until the whole channel is empty, the data follows the first-in, first-out fashion.
The concurrency concept of go is non exhaustive and as much as i want to write more about it , I'm afraid i don't want to clutter up everything in the same article
References
Go Web Programming by Sau Sheong Chang , Manning Publications
Top comments (0)