Some Follow-Up To Previous Comments

A couple of things:

– Further offline discussion with Wayne points out that, if there are memory barrier issues in Java (in its current incarnation), they are JDK problems, not language problems per se, due to the fact that Java guarantees “program order” (causing a permanent performance penalty). The example he gave turned out to need some re-working to really test this correctly.

– The Java synchronization stuff posted doesn’t actually do anything for memory barriers at all in theory, although as it happens, all of the underlying OS synchronization primitives provide implicit memory barriers. Java on an architecture in which synchronization primitives are implemented differently might have a problem.

Rod posted a cool link about Java memory issues. It’s a good thing that I Hate Java, or else I’d have to be concerned about stuff like this. 🙂

– As far as memory barrier references, there are few. The is some discussion in Dekker and Newcommer’s Writing Windows NT Device Drivers, which is old and out of date, but a great book nonetheless. Wikipedia has an article about memory barriers, and they’re covered in the processor manuals for the Pentium 4, Itanium, and AMD64. Note that they’re also sometimes referred to as “fences”. Adrian Oney from Microsoft knows about them; that’s as much as I can say about that though. 🙂 I would really appreciate any additional resources you find.

Leave a Reply

Your email address will not be published. Required fields are marked *