This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Heads-up: volatile and C++

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


  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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]