On Wed, 21 Sep 2005 18:29:03 +0200 Marcus Brinkmann (MB) wrote: MB> I hate to distract from the real issue, but I should note that MB> volatile does not do what you describe here. If you need to make sure MB> that you see the write of another thread, you must use a memory MB> barrier or another proper synchronization primitive. "volatile" is MB> not the answer. I argue that you do NOT need any memory barrier in this case. Cache coherency ensures that as soon as CPU1 writes the relevant cache line with deadline_miss = 1, it goes invalid on CPU0 and the next read from CPU0 for deadline_miss will fetch the cache line from CPU1 and both CPUs go to shared. You need a memory barrier to enforce program order between two loads, two stores or a load and a store (on a particular CPU) on architectures that can reorder such memory operations. The example code does not rely on the order of reads or writes on a particular CPU. It only does: deadline_miss = 0; CPU0: CPU1: ----- ----- if (deadline_miss) deadline_miss = 1; do_something_about_it MB> For an extensive analysis, please see for example sec. 5 in MB> "C++ and the Perils of Double-Checked Locking": MB> MB> http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf This is an example where ordering must be enforced. What is described in this paper is similar to: foo = inited = 0; CPU0: CPU1: ----- ----- foo = 1; while (!inited); //wmb //rmb inited = 1; use foo; Here you must prevent CPU0 from reordering the writes and CPU1 from reordering the reads. -Udo.