« My another $.01 on... | Main | Virtual scrolling... »
20041222 Wednesday December 22, 2004

volatile, thread safety and memory ordering

I came across this excellent write up by Scott Meyers and Andrei Alexandrescu. A lot of people expect more things from volatile than what's defined in the standard and this is a good warning message for them. It also touches on the multiprocessor memory ordering issue and that's another area where a lot of casual programmers are not even aware of. Enjoy the reading! ( Dec 22 2004, 11:58:14 AM PST ) Permalink Comments [2]
Comments:

With the Sun compilers, could garding a section with 
    __asm(".volatile");
    // C/C++ code
    __asm(".nonvolatile");
work around the ordering problem?

Posted by 217.162.219.36 on December 22, 2004 at 02:12 PM PST #

Nope. Sun compiler, at least the SPARC backend, does not pay attention to __asm() stuff - it just passes them through and do whatever it can in between. The usual trick for synchronizing memory access is to insert a call to a function that's defined outside the compilation unit between memory operations that you want to order. As long as the compiler can not see the body of the function, it has to assume the worst and order any global memory operations around the call. Combined with marking accesses volatile, this could make the code MT-safe but unfortunately it is not really portable nor is guaranteed to work in all cases. I don't see any easy way out of this issue, at least in C and C++ unless the language standard incoporates the concept of threads into it. However, if it does so, I suspect it will be too limiting for various hardware platforms....

Posted by Seongbae Park on December 22, 2004 at 11:37 PM PST #

Post a Comment:

Comments are closed for this entry.