> That is only true if you increment len prior to initializing memory on thread > 1. Which I guess may happen due to re-ordering during optimization.
Not only, if you're out of buffer space the second thread might hold a reference to the old buffer, and in between the read, thread 1 copies and frees the old buffer and then you read after free. > The only possible scenario I can think of is if the compiler moves the len > read outside of the iterator, e.g. Compile the code and look at the assembly, for example on Godbolt, why would a compiler assumes they need to reload the length when locally there is no indication that it might change under the compiler feat? > Is that possible? It is _always_ the case. Furthermore on architecture with weak memory models you might get torn reads or torn writes if the memory load and memory store are not specified atomic.
