Classic Concurrency Coding Problems·Q516·Medium
Channels: pass a "token" back and forth over two unbuffered channels. Only the goroutine holding the token may print, so the order is fixed. Each goroutine passes the…
Classic Concurrency Coding Problems·Q517·Medium
Pass a "ball" (a hit counter) between two players. Each player selects on both its input channel and ctx.Done() . The same applies to the send : a send that is not…
Classic Concurrency Coding Problems·Q518·Medium
Build a ring of channels. Goroutine i waits on chs[i] , prints, and then signals chs[(i+1)%3] . Main starts it by putting a token into chs[0] . This generalizes to any…
Classic Concurrency Coding Problems·Q519·Hard
The naive version has every philosopher take the left fork, then the right. If all five grab their left fork at the same time you get a circular wait, which is a…
Classic Concurrency Coding Problems·Q520·Medium
The naive from.mu.Lock(); to.mu.Lock() deadlocks like this. Goroutine 1 runs A->B and locks A. Goroutine 2 runs B->A and locks B. Now each waits for the lock the other…
Classic Concurrency Coding Problems·Q521·Hard
The Cond version uses a ring buffer and two condition variables that share one mutex. Put waits while the queue is full and Take waits while it is empty. Close…
Classic Concurrency Coding Problems·Q522·Hard
The hard part is making the barrier reusable . A fast goroutine can finish phase k and call Wait for phase k+1 before a slow waiter from phase k has even woken up. If…
Classic Concurrency Coding Problems·Q523·Medium
The future is a struct holding the result plus a done channel that is closed exactly once when the result is ready. The Go memory model guarantees that a close…
Classic Concurrency Coding Problems·Q524·Hard
A generator emits 2, 3, 4, ... For every prime p it finds, main adds a filter goroutine to the chain that drops multiples of p . The first value that reaches the end of…
Classic Concurrency Coding Problems·Q525·Hard
There are three concerns: Dedup: a mutex-guarded seen map. You must check and mark it in one critical section , before fetching. Otherwise two goroutines both see "not…
Classic Concurrency Coding Problems·Q526·Hard
Use a fixed pool of workers that read file paths from a channel. Each worker counts into its own private map , so the hot loop needs no locks and has no contention.…
Classic Concurrency Coding Problems·Q527·Hard
Debounce emits the last event only after a quiet period of d . Every new event restarts the timer. Throttle emits at most one event per interval, taking the first one…
Classic Concurrency Coding Problems·Q528·Hard
Hash each key to one of N shards. Each shard has its own RWMutex and a plain map, so operations on different shards never contend. Go 1.24's maphash.Comparable hashes…
Classic Concurrency Coding Problems·Q529·Hard
"Writer-preferring" means that once a writer is waiting, new readers must block, even though the current readers keep going. Otherwise a steady stream of readers starves…
Classic Concurrency Coding Problems·Q530·Hard
Each attempt gets a child context with a per-attempt timeout, and the overall deadline comes from the parent ctx . The attempt runs in a goroutine that writes into a…
Classic Concurrency Coding Problems·Q531·Hard
The supervisor starts the worker with a cancellable context and a beat callback. A timer is reset on every heartbeat. If the timer fires, the worker is considered hung:…