Jon Chery
41 lines
1.2 KiB
Markdown
41 lines
1.2 KiB
Markdown
# Concurrency — First Principles
|
|
|
|
## 1. The Principles
|
|
|
|
### P1. Immutability by Default
|
|
Mutable shared state is the enemy. The default is immutable; mutation
|
|
is justified.
|
|
|
|
### P2. Single Responsibility for Threads
|
|
Each unit of work has one owner. No "anyone can touch this" state.
|
|
|
|
### P3. Boundaries are Locks
|
|
Synchronization happens at well-defined places. Lock scope is
|
|
minimal and explicit.
|
|
|
|
### P4. Determinism Over Speed
|
|
Correct concurrent code is faster than incorrect concurrent code.
|
|
Race conditions are not "fast enough" — they are wrong.
|
|
|
|
### P5. Lock Minimization
|
|
Locks are expensive and dangerous. Lock-free, wait-free, and
|
|
message-passing are preferred where possible.
|
|
|
|
### P6. No Silent Races
|
|
Race conditions are caught, not hidden. Tools (TSan, Go race
|
|
detector) are part of CI.
|
|
|
|
### P7. Cancellation Support
|
|
Every async operation can be cancelled. Cancellation is fast and
|
|
complete.
|
|
|
|
### P8. Timeout Discipline
|
|
Every blocking call has a timeout. Forever is not a duration.
|
|
|
|
### P9. Bounded Queues
|
|
Unbounded queues are memory leaks in disguise. Bounded queues
|
|
expose backpressure.
|
|
|
|
### P10. Test for Race Conditions
|
|
Concurrent code is tested under concurrent load, not just happy-path
|
|
correctness. |