Heads-up: volatile and C++

[Ken Raeburn]

On Apr 16, 2005, at 15:45, Nathan Sidwell wrote:
> It's not clear to me which is the best approach.  (b) allows threads to
> be supported via copious uses of volatile (but probably introduces
> pessimizations), whereas (a) forces the thread interactions to be 
> compiler
> visible (but shows more promise for optimizations).

Is there anything in the language specifications (mainly C++ in this 
context, but is this an area where C and C++ are going to diverge, or 
is C likely to follow suit?) that prohibits spurious writes to a 
location?  E.g., translating:

   extern int x;
   x = 3;
   foo(); // may call pthread_*
   y = 4;
   bar(); // likewise

into:

   x <- 3
   call foo
   r1 <- x
   y <- 4
   x <- r1
   call bar

...  And does this change if x and y are members of the same struct?  
Certainly you can talk about quality of implementation issues, but 
would it be non-compliant?  It certainly would be unfriendly to 
multithreaded applications, if foo() released a lock and allowed it to 
be acquired by another thread, possibly running on another processor.

To make a more concrete example, consider two one-byte lvalues, either 
distinct variables or parts of a struct, and the early Alpha processors 
with no byte operations, where byte changes are done by loading, 
modifying, and storing word values.

My suspicion is that if the compiler doesn't need to know about threads 
per se, it at least needs to know about certain kinds of restrictions 
on behavior that would cause problems with threads.

Ken