Why cannot the compiler optimization issues just be side-stepped by declaring the relevant shared variables volatile?
This turns out to be impractical, for several reasons: • The examples of compiler-introduced data races in the previously cited PLDI paper deal mostly with cases in which a shared variable, say x is already protected by a lock. Hence we would have to require the programmer to declare lock-protected variables, i.e. internal monitor variables, volatile. This was clearly never the intention of the pthread standard. (See the discussion of Memory Synchronization in SUSV3.) More importantly, this turns out to be completely impractical. It is very common to “wrap” single-threaded code in a lock to make it usable in a multithreaded application. This would not be possible if all variables/fields in the single-threaded code now had to be declared volatile. Thread-safe versions of the C++ standard library, effectively rely on this approach, which we believe to be the only viable one. It is also similar to the one adopted by more recent Java container libraries, for example. Requiring volatile dec
Related Questions
- If XFLAT can share global variables between modules then how standard shared variables like errno, stderr, optarg, etc. handled by XFLAT?
- Im having problems getting shared variables to work using PesterCat linked script steps?
- How can I force the compiler to not initialize some RAM variables during startup?
