Nico Williams, on 11/26/2012 03:05 PM wrote:
Vlad, You keep saying that programmers don't understand "barriers". You've provided no evidence of this. Meanwhile memory barriers are generally well understood, and every programmer I know understands that a "barrier" is a synchronization primitive that says that all operations of a certain type will have completed prior to the barrier returning control to its caller.
Well, your understanding of memory barriers is wrong, and you are illustrating that the memory barriers concept is not so well understood on practice.
Simplifying, memory barrier instructions are not "cache flush" of this CPU as it is often thought. They set order how reads or writes from other CPUs are visible on this CPU. And nothing else. Locally on each CPU reads and writes are always seen in order. So, (1) on a single CPU system memory barrier instructions don't make any sense and (2) they should go at least in a pair for each participating in the interaction CPU, otherwise it's an apparent sign of a mistake.
There's nothing similar in storage, because storage has strong consistency requirements even if it is distributed. All those clouds and hadoops with weak consistency requirements are outside of this discussion, although even they don't have anything similar to memory barriers.
As I already wrote, concept of a flat Earth and Sun revolving around is also very simple to understand. Are you still using this concept?
So just give us a barrier.
Similarly to the flat Earth, I'd strongly suggest you to start using adequate concept of what you want to achieve starting from what I proposed few e-mails ago in this thread.
If you look at it, it offers exactly what you want, only named correctly. Vlad -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
