3 ms·
The goalposts have been moved. The claim is that this pattern isn’t suitable for production code. The ground truth is that a compliant Go implementation may ele
by fashion-at-cost 2y ago
The goalposts have been moved. The claim is that this pattern isn’t suitable for production code. The ground truth is that a compliant Go implementation may elect to: crash; read the first value ever set to the variable for the entire lifetime of the program; or behave completely as you’d expect from a single core interleaved execution order. The first is an opt-in, the latter two are up to the whims of the runtime and an implementation may alternate between them at any point.
Is that the kind of uncertainty you want in your production systems? Or is your only requirement that they don’t serve “corrupt” data?
Don’t be “clever”. Use locks.
- kiitos 2y agoYep. And even if you were to lock down the implementation of the compiler, the version of Go you're using, the specific set of hardware and OS that you build on and deploy to, and so on -- that still doesn't indemnify you against arbitrary or unexpected behavior, if your code violates the memory model!
- nebulous1 2y agoI don't disagree, but that's not the claim I was replying to. The question I was asking about was > I understand the need for correct lock-free impls: Given OP's description, simply avoiding read mutexes can't be the way to go about it? I did note that the documentation recommends a lock. > read the first value ever set to the variable for the entire lifetime of the program That is not my reading of the current memory model? It seems to specifically prohibit this behaviour in requirement 3: > 2. w does not happen before any other write w' (to x) that happens before r.
- fashion-at-cost 2y agoIn this context, ”happens before” is not a wall-clock colloquialism but in fact a term of art that is specifically described as: > The happens before relation is defined as the transitive closure of the union of the sequenced before and synchronized before relations. Without synchronization, the degenerate sequencing is perfectly valid. That’s the problem with being “clever” - you miss a definition and your entire mental model is busted.
- nebulous1 2y agoSo, in the situation in the comment OP, with sychronized writes and and unsynchronized reads, what is this "happens before" stipulation prohibiting?
- fashion-at-cost 2y agoA single reader thread cannot read a value written by a write, then later read a value written by a write that happens before the first write.
- nebulous1 2y agoThanks!