You learn something new every day: "The second major issue with ordering we have to be aware of is a thread could write a variable and then, if it reads it shortly after, could see the value in its store buffer which may be older than the latest value in the cache sub-system."
I was skeptical hippo about this because x86 has such a strongly ordered memory model, but lo and behold: "HOWEVER. If you do the sub-word write using a regular store, you are now
invoking the _one_ non-coherent part of the x86 memory pipeline: the store buffer. Normal stores can (and will) be forwarded to subsequent loads from the store buffer, and they are not strongly ordered wrt cache coherency while they are buffered." (Linus, http://yarchive.net/comp/linux/store_buffer.html).
Note that locking primitives include memory fences, that's why you are not confronted with re-ordering problems unless you do lockfree multicore programming.
From my experience, the fence is much costlier than the actual locking (at least on Linux, thanks to Futexes [1]). So unless you're going to put your hands in the dirt and remove the fence, it is useless and error prone to remove the locking, just because you believe it is not necessary.
I was skeptical hippo about this because x86 has such a strongly ordered memory model, but lo and behold: "HOWEVER. If you do the sub-word write using a regular store, you are now invoking the _one_ non-coherent part of the x86 memory pipeline: the store buffer. Normal stores can (and will) be forwarded to subsequent loads from the store buffer, and they are not strongly ordered wrt cache coherency while they are buffered." (Linus, http://yarchive.net/comp/linux/store_buffer.html).