This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
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
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