Golang has built-in instruments for writing concurrent programs. Placing a go statement before a function call starts the execution of that function as an independent concurrent thread in the same address space as the calling code. Such thread is called
goroutine in Golang. Here I should mention that concurrently doesn’t always mean in parallel. Goroutines are means of creating concurrent architecture of a program which could possibly execute in parallel in case the hardware allows it. There is a great talk on that topic Concurrency is not parallelism.
Let’s start with an example of a goroutine:
This program will print
main function message and possibly
goroutine message. I say possibly because spawning a goroutine has some peculiarities. When you start a goroutine the calling code (in our case it is the
main function) doesn’t wait for a goroutine to finish, but continues running further. After calling a
println the main function ends its execution and in Golang it means stopping of execution of the whole program with all spawned goroutines. But before it happens our goroutine could possibly finish executing its code and print the
goroutine message string.
As you understand there must be some way to avoid such situations. And for that there are channels in Golang.
Channels serve to synchronize execution of concurrently running functions and to provide a mechanism for their communication by passing a value of a specified type. Channels have several characteristics: the type of element you can send through a channel, capacity (or buffer size) and direction of communication specified by a
<- operator. You can allocate a channel using the built-in function make:
Channels are first-class values and can be used anywhere like other values: as struct elements, function arguments, function returning values and even like a type for another channel:
For writing and reading operations on channel there is a <- operator. Its position relatively to the channel variable determines whether it will be a read or a write operation. The following example demonstrates its usage, but I have to warn you that this code does not work for some reasons described later:
Now, as we know what channels are, how to create them and perform basic operations on them, let’s return to our very first example and see how channels can help us.
This program will print both messages without any possibilities. Why?
done channel has no buffer (as we did not specify its capacity). All operations on unbuffered channels block the execution until both sender and receiver are ready to communicate. That’s why unbuffered channels are also called synchronous. In our case the reading operation
<-done in the main function will block its execution until the goroutine will write data to the channel. Thus the program ends only after the reading operation succeeds.
In case a channel has a buffer all read operations succeed without blocking if the buffer is not empty, and write operations - if the buffer is not full. These channels are called asynchronous. Here is an example to demonstrate the difference between them:
In this example
message is a synchronous channel and the output of the program is:
As you see after the first write to the channel in the goroutine all other writing operations on that channel are blocked until the first read operation is performed (about 3 seconds later).
Now let’s provide a buffer to out
message channel, i.e. the creation line will look as
message := make(chan string, 2). This time the output will be the following:
Here we see that all writing operations are performed without waiting for the first read for the buffer of the channel allows to store all three messages. By changing channels capacity we can control the amount of information being processed thus limiting throughput of a system.
Now let’s get back to our not working example with read/write operations.
On running you’ll get this error (details will differ):
The error you got is called a deadlock. This is a situation when two goroutines wait for each other and non of them can proceed its execution. Golang can detect deadlocks in runtime that’s why we can see this error. This error occurs because of the blocking nature of communication operations.
The code here runs within a single thread, line by line, successively. The operation of writing to the channel (
c <- 42) blocks the execution of the whole program because, as we remember, writing operations on a synchronous channel can only succeed in case there is a receiver ready to get this data. And we create the receiver only in the next line.
To make this code work we should had written something like:
Range channels and closing
In one of the previous examples we sent several messages to a channel and then read them. The receiving part of code was:
In order to perform reading operations without getting a deadlock we have to know the exact number of sent messages (
count, to be exact), because we cannot read more then we sent. But it’s not quite convenient. It would be nice to be able to write more general code.
In Golang there is a so called range expression which allows to iterate through arrays, strings, slices, maps and channels. For channels, the iteration proceeds until the channel is closed. Consider the following example (does not work for now):
Unfortunately this code does not work now. As was mentioned above the
range will work until the channel is closed explicitly. All we have to do is to close the channel with a close function. The goroutine will look like:
Closing a channel has one more useful feature - reading operations on closed channels do not block and always return default value for a channel type:
This feature may be used for goroutines synchronization. Let’s recall one of our examples with synchronization (the one with
done channel is only used to synchronize the execution but not for sending data. There is a kind of pattern for such cases:
As we close the channel in the goroutine the reading operation does not block and the main function continues to run.
Multiple channels and select
In real programs you’ll probably need more than one goroutine and one channel. The more independent parts are - the more need for effective synchronization. Let’s look at more complex example:
Here we have a function that creates a channel and spawns a goroutine which will populate the channel with three messages in a specified interval. As we see the third channel
c3 has the least interval, thus we except its messages to appear prior to others. But the output will be the following:
Obviously we got a successive output. That is because the reading operation on the first channel blocks for
300 milliseconds for each loop iteration and other operations must wait. What we actually want is to read messages from all channels as soon as they are any.
For communication operations on multiple channels there is a select statement in Golang. It’s much like the usual
switch but all cases here are communication operations (both reads and writes). If the operation in
case can be performed than the corresponding block of code executes. So, to accomplish what we want, we have to write:
Pay attention to the number
9: for each of the channels there were 3 writing operations, that’s why I have to perform 9 loops of the select statement. In a program which is meant to run as a daemon there is a common practice to run
select in an infinite loop, but here I’ll get a deadlock if I’ll run one.
Now we get the expected output, and non of reading operations block others. The output is:
Channels is a very powerful and interesting mechanism in Golang. But in order to use them effectively you have to understand how they work. In this article I tried to explain the very necessary basics. For further learning I recommend you look at the following: