On Wed, 14 Jun 2006 21:32:38 +0100, Matthew Toseland wrote: > My recollection from C etc was that volatile simply means that it can't be > cached in a register ... if we are doing waits and sleeps, and since we
Which would also be an important thing to accomplish in a multi-threaded environment :). The Java version is reallly just an extended version of that, if you think of it. Anyway, if I remember correctly, "volatile" also tells the C compiler that the value of the variable might change unexpectedly - as a result of an interrupt, for example - and thus you can't optimize away subsequent checks; just because you haven't changed the variable since the last check doesn't mean that it's value must still be the same. I could be wrong here, I was still programming under DOS when I last ran into "volatile" in C while looking around Allegro librarys source, AFAIR. Google brought up another link, this time to what volatile means in C - seems like I was right: http://publications.gbdirect.co.uk/c_book/chapter8/const_and_volatile.html > never write to the variable, I would have thought the compiler would be > smart enough to not do this in any case... And all architectures on which Actually, if the variable's value is never changed, wouldn't a smart compiler simply replace the whole variable with a static value - or just optimize the whole check away, because it will always return the same result ?-) Anyway, you can't trust compiler intelligence for correct functioning of the code. That is up to the language specification. Compiler intelligence is for performance optimization. > linux runs (i.e. effectively all architectures!) have cache coherent SMP. Even NUMA systems ? In any case Java runs on more than just Linux systems. > And ints are atomic on almost all systems. In practice, the watchdog > mechanism is known to work. In Java, ints (and all 32-bit variables) are atomic on all systems. It's part of the JVM definition, AFAIK. > Anyway, that's a very interesting page, and I will make the variable > volatile, as it says... Good. > "In particular, it is always wrong to write loops waiting for values > written by other threads unless the fields are volatile or accessed via > synchronization (see ?3.2.6)." > > Also the point about starting threads in constructors in non-final classes > may impact us. It is also possible that some code violates this: Uh oh. I've seen code that started threads from constructors (in FreeCol) break (begin throwing NullPointerExceptions) just by changing the garbage collector, and begin functioning properly when I fixed the code (moved the thread starting into another method and changed all places that created objects into looking like "new SomeObject().startThreads()"). Anyway, if there's such code in Freenet, it *will* cause problems. > "The model also allows inconsistent visibility in the absence of > synchronization. For example, it is possible to obtain a fresh value for > one field of an object, but a stale value for another. Similarly, it is > possible to read a fresh, updated value of a reference variable, but a > stale value of one of the fields of the object now being referenced." > > On Wed, Jun 14, 2006 at 10:16:47PM +0300, Jusa Saari wrote: >> On Wed, 14 Jun 2006 13:57:38 +0100, Matthew Toseland wrote: >> >> > On Wed, Jun 14, 2006 at 12:59:56PM +0300, Jusa Saari wrote: >> >> On Tue, 13 Jun 2006 20:34:05 +0100, Matthew Toseland wrote: >> >> >> >> > On Tue, Jun 13, 2006 at 10:26:55PM +0300, Jusa Saari wrote: >> >> >> What happens if the watchdog gets stuck too ? It has to >> >> >> synchronize with the watched thread sometimes to do its work, >> >> >> AFAIK. >> >> > >> >> > It just reads a variable. An int. Without synchronization. >> >> >> >> I hope that's a "volatile" variable ? >> > >> > Is that necessary? >> >> Yes. It guarantees that the watchdog thread sees any updates made by the >> watched thread, instead of seeing a possibly stale value in local CPU >> cache. Not using "volatile" keyword in variable declaration is not an >> issue in an X86 platform, since the X86 architechture gives stricter >> cache coherency guarantees than Java Memory Model, but it's going to >> lead to really nasty bugs in any architechture that doesn't give them. >> >> Basically "volatile" guarantees that each thread will see the changes >> made by any other thread, without needing to synchronize. It also >> guarantees that longs and other larger-than-32-bit variables will be >> read and written atomically, but that doesn't matter for ints, >> obviously. >> >> Here's a bit more info - see the bottom of the page: >> >> http://g.oswego.edu/dl/cpj/jmm.html >> >> _______________________________________________ Devl mailing list >> [email protected] >> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl >> _______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
