Tomash Brechko writes: > > Several people already suggested to use volatile for shared data. > Yes, it will help because we know it will disable all access > optimizations, including thread-unaware ones. But I don't want to > disable _all_ optimizations, I rather vote for thread-aware > optimizations.
But your plan would disable optimizations even when it isn't necessary to do so. Only a small part of the data in a multi-threaded program are shared. > There is no requirement in POSIX to make all shared data volatile. > As the article referenced in the thread explains, there is no > agreement between POSIX and C/C++ wrt memory access. But should it > be fixed in the compiler (as article suggests), or should every > shared data in every threaded program be defined volatile, just for > the case? I never seen latter approach in any Open Source project > (though didn't look for it specifically), and many of them are > considered quite portable. > > Again, we are not discussing some particular code sample, and how it > might be fixed, but the problem in general. Should GCC do > thread-unsafe optimizations, or not? We do understand what you're saying, and simply repeating the same thing doesn't help. I think we should wait to see what the C++ working group comes up with and consider implementing that, rather than some ad-hoc gcc-specific proposal. There's some discussion here: http://www.artima.com/cppsource/threads_meeting.html and here: http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/ Andrew.
