The document describing WebAssembly threads says:
Atomic load/store memory accesses behave like their non-atomic counterparts, with the exception that the ordering of accesses is sequentially consistent.
This is in reference to i32.atomic.load versus i32.load, i32.atomic.store versus i32.store, etc.
What does it mean that the non-atomic operations aren't sequentially consistent? In what situations would the non-atomic operations not be suitable?
The memory consistency of atomic operation define (the minimum requirement of) how atomic accesses are sequenced by the processor in relation to other variable. This is related to memory barrier. A relaxed atomic operation cause the atomic operation to be sequenced independently of other variables. This means that if you do:
non_atomic_variable = 42;
atomic_increment(atomic_variable);
Then, other threads may not see the updated value of non_atomic_variable when atomic_variable has been increased by the current thread. This is not possible in a sequentially consistent memory ordering because the compiler should use instructions so that there is a memory barrier forcing other threads to see the updated value when the increase is done and the atomic operation (eg. read) is sequenced from other threads.
A sequentially consistent memory ordering is safe but also slow. A relaxed memory ordering is fast because of weaker synchronizations (and more room for processors optimizations during load/stores). For example, with a relaxed memory ordering, a processor can execute the non_atomic_variable later because of a cache miss (thanks to an out-of-order execution). With a sequentially consistent memory ordering, the increment need to wait for the store to be done which can take some time when there is a cache miss.
Note that the memory ordering of the processor can be stronger than the one required by the software stack (eg. x86-64 processor have a strong memory ordering).