https://github.com/maki3cat/gogymnastics
concurrency patterns of Golang summarized during my implementation of Raft
https://github.com/maki3cat/gogymnastics
concurrency concurrency-patterns golang golang-examples
Last synced: 5 months ago
JSON representation
concurrency patterns of Golang summarized during my implementation of Raft
- Host: GitHub
- URL: https://github.com/maki3cat/gogymnastics
- Owner: maki3cat
- License: mit
- Created: 2025-04-05T15:29:11.000Z (9 months ago)
- Default Branch: main
- Last Pushed: 2025-08-03T02:48:30.000Z (5 months ago)
- Last Synced: 2025-08-03T04:20:50.617Z (5 months ago)
- Topics: concurrency, concurrency-patterns, golang, golang-examples
- Language: Go
- Homepage:
- Size: 3.42 MB
- Stars: 3
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: Readme.md
- License: LICENSE
Awesome Lists containing this project
README
This repo including this readme is still Growing :)
Still, hope you like it and star it :star:
## Concurrency
### Basic Primitives
- chan: rendezvous chan, buffered chan; (share by communication)
- sync: cond, lock, pool/once, etc; (communicate by sharing)
- sync/atomic: relatively lowerlevel primitives with atomic Swap
## Patterns Summarized
please read the code in
- concurrency (haven't sized up yet)
- concurrency_small
- concurrency_medium
## Principles
1. whenever using goroutins: check goroutine leakage / goroutines should be preemptable/interruptable/able to exit
- either waiting on `ctx.Done` with only small units in between
- either the code is non-blocking and exits almost instantenously
- (*usually channels that are not closed don't cause the memory leak of the chan, but may trigger goroutine leakage if there is some goroutine only exiting on the channel's close signal)
2. most of the time when reading from a `chan`, read the ok flag, `data, ok := <- someChan`
3. we can use buffered `chan` to avoid goroutine leakage
4. if there is only one channel to read from which is sure to be closed, consider `for range` than `for select` in the first place; but if the channel is not closed, this for range may block forever without a chance to read from `ctx.Done`;
5. `cancel()` should "always" be called when the caller generated the `cxt, cancel` exits
6. very very rare problem solving requires the leverage of `tryLock/tryUnlock`