[cpp-threads] RE: Ping on memory model and concurrency

[Herb Sutter]

> Making this true has a significant impact on existing compilers.  An
> astonishingly simple example that I used in my PLDI talk, though not
the
> paper, is the following loop, which adds the number of elements of a
list
> to the global variable 'count':
> 
> for (p = list; p != 0; p = p -> next) ++count;
> 
> As far as I can tell, nearly every optimizing compiler naively
promotes
> 'count' to a register.  This is almost certainly wrong, in that
'count' is
> written even if the list is empty, and it can thus introduce a data
race.
> Although it is very unlikely to break code in practice, it can break
code
> that is fully synchronized using locks.  And most programmers would
have
> zero chance of debugging the result.  

Is that an unexpected data race, or just a classic data race? I would
assume that the program should be doing an interlocked increment on
count anyway, or explicit memory fences for count when the thread
executes the loop. No?

I'm probably misunderstanding the example. Clarification would be
appreciated.

> Current specifications are ambiguous
> with respect to things like this; fixing that is my top priority.  So
long
> as compilers are allowed to introduce unexpected data races, we have
no
> hope of teaching programmers to write correct multithreaded code.

Completely agree.

Herb