We touched on CSP briefly in the previous chapter, but it's worth exploring a bit more in the context of how Go's concurrency model operates.
CSP evolved in the late 1970s and early 1980s through the work of Sir Tony Hoare and is still in the midst of evolution today. Go's implementation is heavily based on CSP, but it neither entirely follows all the rules and conventions set forth in its initial description nor does it follow its evolution since.
One of the ways in which Go differs from true CSP is that as it is defined, a process in Go will only continue so long as there exists a channel ready to receive from that process. We've already encountered a couple of deadlocks that were the result of a listening channel with nothing to receive. The inverse is also true; a deadlock can result from a channel continuing without sending anything, leaving its receiving channel hanging indefinitely.
This behavior is endemic to Go's scheduler, and it should really only pose problems when you're working with channels initially.
Note
Hoare's original work is now available (mostly) free from a number of institutions. You can read, cite, copy, and redistribute it free of charge (but not for commercial gain). If you want to read the whole thing, you can grab it at http://www.cs.ucf.edu/courses/cop4020/sum2009/CSP-hoare.pdf.
The complete book itself is also available at http://www.usingcsp.com/cspbook.pdf.
As of this publishing, Hoare is working as a researcher at Microsoft.
As per the designers of the application itself, the goal of Go's implementation of CSP concepts was to focus on simplicity—you don't have to worry about threads or mutexes unless you really want to or need to.
You may have heard of the dining philosophers problem, which describes the kind of problems concurrent programming was designed to solve. The dining philosophers problem was formulated by the great Edsger Dijkstra. The crux of the problem is a matter of resources—five philosophers sit at a table with five plates of food and five forks, and each can only eat when he has two forks (one to his left and another to his right). A visual representation is shown as follows:
With a single fork on either side, any given philosopher can only eat when he has a fork in both hands and must put both back on the table when complete. The idea is to coordinate the meal such that all of the philosophers can eat in perpetuity without any starving—two philosophers must be able to eat at any moment and there can be no deadlocks. They're philosophers because when they're not eating, they're thinking. In a programming analog, you can consider this as either a waiting channel or a sleeping process.
Go handles this problem pretty succinctly with goroutines. Given five philosophers (in an individual struct, for example), you can have all five alternate between thinking, receiving a notification when the forks are down, grabbing forks, dining with forks, and placing the forks down.
Receiving the notification that the forks are down acts as the listening channel, dining and thinking are separate processes, and placing the forks down operates as an announcement along the channel.
We can visualize this concept in the following pseudo Go code:
type Philosopher struct {
leftHand bool
rightHand bool
status int
name string
}
func main() {
philosophers := [...]Philospher{"Kant", "Turing",
"Descartes","Kierkegaard","Wittgenstein"}
evaluate := func() {
for {
select {
case <- forkUp:
// philosophers think!
case <- forkDown:
// next philospher eats in round robin
}
}
}
}This example has been left very abstract and nonoperational so that you have a chance to attempt to solve it. We will build a functional solution for this in the next chapter, so make sure to compare your solution later on.
There are hundreds of ways to handle this problem, and we'll look at a couple of alternatives and how they can or cannot play nicely within Go itself.