on Sat Jul 30 2011, Gordon Woodhull <gordon-AT-woodhull.com> wrote:
On Jul 30, 2011, at 8:40 AM, Dave Abrahams <dave@boostpro.com> wrote:
on Fri Jul 29 2011, Gordon Woodhull <gordon-AT-woodhull.com> wrote:
On Jul 29, 2011, at 7:36 PM, Dave Abrahams <dave@boostpro.com> wrote:
Personally I never understood how sequential consistency could be much of a help in reasoning about multithreaded programs... but that's just me.
True, it's bad enough with sequential consistency, but without it there's no hope of understanding at all IMO.
I think I meant the opposite, or nearly so. How does not having sequential consistency make reasoning worse?
I must be missing something. Without it you can't depend on the order of operations even within one block and one thread, right?
Doesn't the (C++03) standard make some guarantees about sequence points that make ordering well-defined in the single-threaded case, without ever introducing the notion of sequential consistency?
E.g. we were talking about translating concurrent pseudocode to real code. Without sequential consistency it might require inserting memory barriers and it's never clear where, or if some other architecture is going to need different ones.
How is it not better to at least understand that a single piece of code will do what it says in the same order?
Could you show me an example of some single-threaded code that can't be understood on the basis of the C++03 standard alone, and give some examples of the multiple possible interpretations of its semantics? -- Dave Abrahams BoostPro Computing http://www.boostpro.com