- Req: The Go Memory Model
- The first section was fairly basic, and Concurrency in Go covered pretty much all of the more advanced bits.
Use threads when they make code easier to reason about, not for performance
Closures don’t pass-by-value unless you pass a non-pointer argument explicitly
Cond implements a condition variable, a rendezvous point for goroutines waiting for or announcing the occurrence of an event.
Each Cond has an associated Locker L (often a *Mutex or *RWMutex), which must be held when changing the condition and when calling the Wait method.
A Cond must not be copied after first use.
Waitrequires holding the lock to prevent the lost wakeup problem, where
Broadcastmay be called when the other thread is checking the condition and hasn’t called
Suggests that channels should be used sparingly in favor of locks, which seems antithetical to Go’s stated goals with channels.
- Deadlocks when peers are waiting on each other’s response