This is absolutely not true. If your program is not race free, then you're going to have problems no matter what your concurrency model is. The memory model is

This is absolutely not true. If your program is not race free, then you're going to have problems no matter what your concurrency model is. The memory model is not a property of the program, it's a property of the platform - since in Java you're programming to the JVM platform, the fact that the platform is very exactly specified is what allows you to show that your program is race free. I think you're looking for a very different sort of specification than what the JMM provides. It doesn't provide you with exact specifications of exactly how threads will behave, but no system that I'm aware of completely specifies that and any program that relies on that is fundamentally broken on any platform except exactly one version of one platform anyway - that which it was written and tested on. It's simply too dependent on the exact OS and version, the exact version of the processor, and a million other factors you can't control. Instead, the JVM, the JMM and company work together to exactly specify the interactions between threads that are safe. It turns out that this really is all you need to know to write correct concurrent programs, and you don't have to worry about combinations of anything, or how threads are implemented, or how many processors are available, etc etc. Additionally, with the j.u.c libraries in Java 5+ there are sufficiently good abstractions that you don't need to worry about any of this low level gore much. Seriously, if you're going to be writing multithreaded code in Java, read the book. It's awesome.