Subj : Re: [.NET] Volatile Fields To : comp.programming.threads From : David Hopwood Date : Sat Sep 17 2005 03:23 pm Cool Guy wrote: > David Hopwood wrote: > >>It doesn't need to be. Because 'finished' is volatile, the assignment >>"finished = true;" causes previous writes by Thread2 (whether or not they >>are to volatile variables) to be "performed" before the write to 'finished'. >>This is what the page means by 'A volatile write has "release semantics"'. > > But couldn't *result* be written to a cache instead of to main memory? In this case cache is a transparent optimization; it plays no part in the memory model. At the implementation level, 'result' may well be written to a cache, but typically the cache will be "snooped" by other processors so that they can see the write. >>In addition, the access to 'finished' in "if (finished) ..." guarantees >>that writes performed before 'finished' became true are visible to the >>Main thread. This is what the page means by 'A volatile read has "acquire >>semantics"'. > > But couldn't *result* be read from a cache instead of from main memory? Ditto. Note that in principle, cache does not *necessarily* have to be transparent; a memory model could include some abstraction that corresponds to a per-thread cache (the original Java memory model did something like this). But .NET's model doesn't. -- David Hopwood .