In the context of memory with WB cache.

On 1 core, non-same-location loads can happen before stores (and with speculative execution it is even more true).

But in a multicore scenario, what are the cases to be very careful about?

For instance, since cores can share some cache, how to push some stores stuck into the write buffers of one core out in order to be "seen" by the other cores?
[ms]fence and other "serializing instructions" are "violent" as they push everything down to dram memory and pushing down to the first level of shared cache between cores should be enough.

All the magic for cache coherency is done by the MESI protocol.

You don't have to worry about it. You have no control over it anyway. And it works just fine.

Interesting.

I had a look at this wikipedia article, and there is a store buffer section.

But there, they say that a memory barrier will flush the store buffer up to the cache only, but I recall reading amd datasheet about memory ordering, memory barriers would flush stores to the dram.

Am I delusional? Unable to read a datasheet?

Depending upon the CPU and system configuration a memory barrier instruction might force all data to be coherent all the way to the DRAM (very slow), or just to the highest level cache (less slow). It really doesn't matter though as long as the CPU delivers a consistent state to all the cores.

Using a memory barrier in user code is very rare, and not needed usually. Most usage is to synchronise and order data for external peripherals.

Note that this is mostly true for x86 CPUs since they have strong memory ordering. It's not the same on other CPU architectures where you need to add barriers in a lot of cases with multi-threading.

RISC-V is one of those architectures, where you have to program like this as far as I know.

That said, iret on x86_64 is a synchronizing instruction, "locked xchg" instruction too, so it sort of happens all the time on x86_64.