Today, POSIX is a bible.

Following is an excerpt from a paper; sorry, I forgot the source.
—————————

Here is what we can assume is safe to do when using POSIX (quoting [Butenhof]):

1. Whatever memory values a thread can see when it creates a new thread can also be seen by the new thread once it starts. Any data written to memory after the new thread is created may not necessarily be seen by the new thread, even if the write occurs before the thread starts.

2. Whatever memory values a thread can see when it unlocks a mutex (leaves a synchronized method or block in Java), either directly or by waiting on a condition variable (calling wait in Java), can also be seen by any thread that later locks the same mutex. Again, data written after the mutex is unlocked
may not necessarily be seen by the thread that locks the mutex, even if the write occurs before the lock.

3. Whatever memory values a thread can see when it terminates, either by cancellation, returning from its run method, or exiting, can also be seen by the thread that joins with the terminated thread by calling join on that thread. And, of course, data written after the thread terminates may not necessarily be seen
by the thread that joins, even if the write occurs before the join.

4. Whatever memory values a thread can see when it signals or broadcasts a condition variable (calling notify in Java) can also be seen by any thread that is awakened by that signal or broadcast. And, one more time, data written after the signal or broadcast may not necessarily be seen by the thread that wakes up, even if it occurs before it awakens. In addition to the guarantees specified in [Butenhof], I will add a Java-specific rule that we have already discussed:

5. Any memory values assigned during static initialization are visible to all threads. (The reason being that the JVM will follow rule 1 or 2 from [Butenhof] or will manually insert memory barriers as appropriate to preserve this property— as is necessary to ensure that the loaded class is visible.)

I assert that these rules are reasonable assumptions to make about any existing JVM, and should be made the standard rules for programmers to code to. Any JVM that does not use native threads will appear to a multiprocessor machine as a single threaded process. As such, those JVMs will not have any of the races discussed in this article caused when two processors attempt to access the same data at the same time. For those JVMs that use native threads, the native threads used either are POSIX threads (pthreads) or are a thread library compatible with pthreads. The reason is that all major operating systems support POSIX threads and must provide these guarantees for the pthreads library. These guarantees are also a minimal set needed for threads on a multiprocessor to be useful. The last rule that I added that was not specified in
[Butenhof] simply states that any JVM that claims to be usable on a multiprocessor must either follow the POSIX rules, or must use knowledge of the underlying multiprocessor to guarantee the visibility of loaded classes.