On Thu, Jun 15, 2006 at 12:45:02AM +0300, Jusa Saari wrote: > > 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.
Well, Opterons are cache coherent, and they're NUMA. :) I believe so; non-cache-coherent multiprocessing is a major PITA, and therefore rather rare, I'd be very surprised if it was supported... > > > 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. Indeed. > > > 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. There is, though we always start the thread at the end of the constructor, and as I understand that page Thread.start() will flush everything in the surrounding code first... File a bug, or hack on it yourself. > > > "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 > -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so.
signature.asc
Description: Digital signature
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
