Subj : Re: Can C++ local static objects be made thread safe? To : comp.programming.threads From : David Schwartz Date : Sun Jan 23 2005 01:35 pm "David Hopwood" wrote in message news:VWTId.204172$Z7.36627@fe2.news.blueyonder.co.uk... >>> That's not obvious. Assuming preemptive multithreading, memory barriers >>> are still needed on a uniprocessor to limit compiler reordering. >> Wouldn't the volatile keyword indicate that to the compiler ? > Not in general. If it does then it is only due to a coincidence of the > implementation of that compiler. It's at least theoretically possible that someone could design a complier where 'volatile' has this particular effect. But in practice nobody does this. One reason is that if it had this effect in addition to its normal affect, the overhead would be greater than is necessary for either purpose alone. Another is that even if it was just for thread synchronization, the overhead would still be greater than is generally necessary because the compiler wouldn't know when synchronization was needed and would be forced to put it before and after all operations. Finally, it wouldn't be possible to do so portably, because some platforms can't do certain operations atomically or safely without explicit locks and it wouldn't be clear what else needed to be locked. Consider 'i=i+1' where 'i' is a volatile short integer on a platform that can't do a 16-bit write. DS .