Simon Farnsworth wrote: > Further, the standard is silent on whether you can assume strict > consistency, weak consistency, sequential consistency, causual consistency, > or another consistency model.
> These are both important if you want to guarantee that an operation between > two threads working in parallel on the same block of memory does what you > expect. In a weak consistency model, it's impossible to implement a working > mutex without knowing which operations are synchronisation operations; your > environment typically handles this by arbitrarily declaring that some > library calls are synchronisation operations.
I am happy to admit, I have no idea what these terms mean, but I will look them up in about 10 minutes.
However, I see something missing in your post: atomic operations. This is the essence of my thesis. I keep saying there will not be any guarantees in any language if you do not have:
1. Harwdware-based atomic operations. 2. OS Support of synchronization.
People keep responding by demonstrating or alluding to C++ code that is bound to not behave the way the programmer expected it to.
If that is the case, then I have said that a 1000 times:
No programmer in the world who is going to "implement safe threading in C++" by writing generic C++ code without regard for 1 & 2 above. *That* is where the guarantees come from.