An intuitive analogy to memory barriers:

• two threads running on two cpu with their own L1 cache are like two person collaboratively editing files on their computer, connected to central file repo.
• on each person's own computer is a working copy (L1 cache) of the files (memory locations) that correspond to the the central repo (memory, or shared cache like L2)
• each person's computer randomly issue pull and push operations on the files (note that each file is push/pulled independently unlike git). the intuition captures the unpredictable nature of cache flushes and misses, where each cache line operates individually.
• when collaborating on a file, a person should manually pull on a file before editing. but that's of no use if the other person don't push after their write. but if both party collaborates, there will be no inconsistency.
• the pull operation is equivalent to a loadload fence, captured by acquire semantics. the push operation is equivalent to a storestore fence, captured by release semantics.
• the loadstore fence ensures the out-of-order execution doesn't happen around the barrier such that read always happens before the barrier and write always after the barrier. there is no simple version control analog, but both loadload and storestore implies the loadstore fence.
• the storeload fence ensures the write before the barrier always before reads after the barrier.

In addition to that, some of my own notes:

• relaxed semantics uses special cpu instructions (e.g. LOCK) to skip using non-shared caches (i.e. L1), this ensures all cores access to the same data.
• acqrel semantics uses three operations together: pull, change, push.
• seqcst semantics, on top of acqrel guarantee, ensures a total order of load and store. it can be implemented by cpu waiting for the pipeline to finish and flushing the caches before issuing future instructions. (my speculation)