Re: [boost] [lockfree] review

Subject: Re: [boost] [lockfree] review
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-07-30 21:44:35

on Sat Jul 30 2011, Gordon Woodhull <gordon-AT-woodhull.com> wrote:

> On Jul 30, 2011, at 5:10 PM, Dave Abrahams wrote:
>> on Sat Jul 30 2011, Gordon Woodhull <gordon-AT-woodhull.com> wrote:
>>> 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?
>
> No.  Sorry, I meant that it's difficult or impossible to reason about
> a multithreaded program unless the sequence of operations in the
> individual threads is clear.
>
> It's still very difficult to reason with sequential consistency but
> it's better than having to consider the higglety-pigglety reordering
> optimizations of the compiler and processor.
>
> I'm surprised that you don't think it will help - care to shed any
> light (or darkness)?

No program of substantial size can be understood "dynamically."  You
can't think about code paths and timing and control flow; there are just
too many combinations and too much to keep track of.  You have to think
of static things like preconditions, postconditions, and invariants.
That's why purely functional languages are easier to reason about, and
why const and value semantics are important in languages with mutation.

That's also why it's always seemed to me that thinking in terms of
interleavings of instructions doesn't lead to any fundamentally improved
ability to understand parallelism: it doesn't change anything from a
static point of view.  The basic issue is still one of protecting one
thread from observing the broken invariants of another.

Of course, I could well be missing something.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com