Concurrency

Put go in front of a function call and it runs concurrently with the rest of your program, scheduled by the Go runtime instead of the OS. Starting one is the easy part. The hard part is getting two goroutines to hand off a result without stepping on each other’s state, and that’s the job channels do. What is a goroutine? A goroutine is a function running independently of the one that started it, managed by Go’s runtime rather than the operating system. An OS thread reserves a megabyte or more of stack and costs the kernel real time to schedule. A goroutine starts with a stack of about 2KB that grows as needed, and the runtime multiplexes many goroutines onto a handful of OS threads. Starting thousands of them is normal. ...

Two requests hit the same “withdraw $100” endpoint half a millisecond apart. The account has $150. Both requests read that balance, both see enough funds, both approve, both subtract $100. The account ends at -$50, and no branch in the code should have allowed it. That is a race condition: the output depends on which operation happens to finish first, and “first” was never something the code decided. What causes a race condition? You need two ingredients at once: shared mutable state, and more than one path of execution touching it without coordination. The paths can be threads, async tasks, processes, or two servers hitting the same database row. Take away either ingredient and the bug disappears. A single thread can’t race against itself, and immutable state can’t be corrupted by being read twice. ...