That is a known issue in Seed 1. It should be fixed in a future seed.
Post not yet marked as solved
'Correct code' in this context is code that uses memory barriers to declare what memory consistency requirements you have to avoid data races.
data race --> use of a memory location by two or more threads without adequate synchronization.
consistency --> constraining what order memory accesses must occur in to avoid a data race
For example, when using C++11 and accessing a shared variable, you'd typically use a std::mutex or similar, or when using a std::atomic as a signal between threads you'd use acquire/release or seq_cst memory ordering
The x86_64 architecture naturally provides fairly strong memory ordering rules, so even if you entirely omit the use of memory barriers in your code, you have a data race but you often get the results you expected. The ARM architecture is weakly ordered: the CPU is permitted to aggressively reorder memory accesses to improve performance, and that data race that existed all along is now much more likely to reveal itself.
(note, even on x86_64, the compiler would have been free to reorder your memory accesses even if the hardware didn't, so those missing barriers are still dangerous there. It is generally just down to luck what ends up happening).
