Lectures

We break down why you need sync.Mutex in concurrent Go code, where a data race starts, how to выделать critical sections, and how to follow the Lock() → Unlock() discipline. We will show the defer idiom for releasing a lock, discuss its limits (especially inside loops), build a thread-safe TaskStore (methods Add, Get, ListSnapshot), and analyze what deadlock scenarios look like and the typical mistakes.

We break down how sync . RWMutex works in Go: how read-lock and write-lock differ, how to correctly protect map and slices from races, why it is dangerous to expose “live” collections (aliasing), when RWMutex actually speeds up frequent short reads, and when it adds overhead and latency. We also discuss the forbidden “upgrade” RLock() → Lock(), the double-check pattern, and common mistakes that lead to a data race or hangs.

We break down when it actually makes sense to use sync/atomic in Go: for independent counters and flags ( atomic.Int64, atomic.Bool), operations Add/ Load/ Store and CAS ( CompareAndSwap, “first wins”). Using TaskStore as an example, we show how to combine atomics with sync.RWMutex, and we also draw clear boundaries of applicability: where you need a Mutex for invariants and which mistakes most often break concurrent code.

We break down how, in concurrent Go code, to guarantee “initialize exactly once” using sync.Once: why the naive if + nil check leads to data races, how the Once.Do contract works, why Once must not be copied after first use, why recursive calls to Do are dangerous (deadlock), and how correct memory visibility relates to the Go memory model (“synchronizes before”). We reinforce everything with examples: lazy initialization of a map, keeping Once inside a struct, and storing the result/error because Do returns nothing.

We break down what kinds of mutable state exist in a Go application at different layers ( app, storage, cache), who owns the data, and which synchronization primitives to choose: Mutex for invariants, RWMutex for frequent reads, atomic for simple counters. With examples, we cover operation deduplication, in-memory storage, file writes, a cache wrapper with invalidation, and common mistakes (a global lock, long critical sections, and leaking internal structures to the outside).