> else it can reorder instructions so that your clever tricks fail
I don't understand how instruction re-order will cause the example to fail
under the constraints given (one writer which strictly increases the shared
`len` variable).
The reader thread would be simply:
iterator items(self: MyContainer): int =
for i in 0..<self.len:
yield self.arr[i]
# ... within the reader thread
for x in myCont:
echo x
Run
How would the compiler re-order the read here? If `self.len` is read each
iteration, i.e. increases mid-iteration (which you could avoid via a temp var),
you'll be guaranteed to not read invalid memory in this scenario.
> Likewise, the read from the length does not use atomics.load
Is there a reason why `atomics.load` requires a `var Atomic[T]`? i.e. with an
atomic the above iterator would require to be declared as `iterator items(self:
var MyContainer): int`
`std::atomic<T>::load` is a const function (std/atomics appears to wrap this in
cpp backend)
