Haseeb Raja
@haseebraja.bsky.social
I like privacy in its purest form. I like points and spaces. I like Go and I am learning cryptography. Søren’s intensity, Camus’ solution, Spinoza's World. Chuckling at the absurdity of myself. #OpenToWork
10/10 Practical checklist: Use channels or mutexes for most shared state, reach for atomics only in focused cases, always run go test -race, and remember, if goroutines share memory without synchronization, Go makes no visibility guarantees.
More on go memory model at skoredin.pro/blog/golang/...
More on go memory model at skoredin.pro/blog/golang/...
Go Memory Model Deep Dive: What Every Go Developer Must Know
Production bug from lost orders. One-line fix with atomic operations. Complete guide to Go's memory model without fluff.
skoredin.pro
November 23, 2025 at 7:37 PM
10/10 Practical checklist: Use channels or mutexes for most shared state, reach for atomics only in focused cases, always run go test -race, and remember, if goroutines share memory without synchronization, Go makes no visibility guarantees.
More on go memory model at skoredin.pro/blog/golang/...
More on go memory model at skoredin.pro/blog/golang/...
9/ Lock free structures such as a stack built with compare and swap rely on the same rules. CAS acts as a full memory barrier, so once it succeeds, other goroutines see a consistent node state even though no mutex was involved.
November 23, 2025 at 7:37 PM
9/ Lock free structures such as a stack built with compare and swap rely on the same rules. CAS acts as a full memory barrier, so once it succeeds, other goroutines see a consistent node state even though no mutex was involved.
8/ Classic trap, a data field plus a ready flag. If you write the data, then set ready with a plain write, the CPU may reorder them, and another goroutine can see ready set while data is still stale. Use atomic store and load on the flag.
November 23, 2025 at 7:37 PM
8/ Classic trap, a data field plus a ready flag. If you write the data, then set ready with a plain write, the CPU may reorder them, and another goroutine can see ready set while data is still stale. Use atomic store and load on the flag.
7/ Atomic operations from the atomic package in the standard library provide strict memory barriers. A Store keeps earlier writes before it, and a later atomic Load will see them. This is how you safely implement counters, flags, and ready bits.
November 23, 2025 at 7:37 PM
7/ Atomic operations from the atomic package in the standard library provide strict memory barriers. A Store keeps earlier writes before it, and a later atomic Load will see them. This is how you safely implement counters, flags, and ready bits.
6/ Mutexes give simple ownership over a critical section. An Unlock in one goroutine happens before a later Lock on the same mutex, so all writes done while holding the lock become visible to the goroutine that acquires it next.
November 23, 2025 at 7:37 PM
6/ Mutexes give simple ownership over a critical section. An Unlock in one goroutine happens before a later Lock on the same mutex, so all writes done while holding the lock become visible to the goroutine that acquires it next.
5/ Channels are one of the safest ways to publish data. A send on a channel happens before the matching receive, and closing a channel happens before a receive that observes the closed state, so the receiver sees all prior writes.
November 23, 2025 at 7:37 PM
5/ Channels are one of the safest ways to publish data. A send on a channel happens before the matching receive, and closing a channel happens before a receive that observes the closed state, so the receiver sees all prior writes.
4/ To make updates visible, you need a happens before relationship. In practice, that comes from synchronization primitives, channels, mutexes, or atomic operations. Without that edge, the compiler and CPU may reorder reads and writes.
November 23, 2025 at 7:37 PM
4/ To make updates visible, you need a happens before relationship. In practice, that comes from synchronization primitives, channels, mutexes, or atomic operations. Without that edge, the compiler and CPU may reorder reads and writes.
3/ Core rule. If two goroutines access the same memory at the same time and at least one of them writes and there is no synchronization, Go gives you no guarantees. Treat that as a bug, even if your tests look fine.
November 23, 2025 at 7:37 PM
3/ Core rule. If two goroutines access the same memory at the same time and at least one of them writes and there is no synchronization, Go gives you no guarantees. Treat that as a bug, even if your tests look fine.
2/ Almost every serious concurrency bug is the same question, "I wrote a value, so why did the other goroutine not see it." Usually, because the data was written but not safely published, so the reader saw a stale copy.
November 23, 2025 at 7:37 PM
2/ Almost every serious concurrency bug is the same question, "I wrote a value, so why did the other goroutine not see it." Usually, because the data was written but not safely published, so the reader saw a stale copy.
1/ Go memory model defines when a write in one goroutine is guaranteed to be seen by another. Ignore it, and you get bugs like lost increments or missing orders that never show up in tests, but appear under real production load.
November 23, 2025 at 7:37 PM
1/ Go memory model defines when a write in one goroutine is guaranteed to be seen by another. Ignore it, and you get bugs like lost increments or missing orders that never show up in tests, but appear under real production load.