does a thread start causes a memory barrier (shared variables will be persisted in memory)?

I wonder i开发者_如何学Cf invoking a thread start has the safe effect of updating a volatile or after acquiring a lock?

to quote http://download.oracle.com/javase/6/docs/api/java/util/concurrent/package-summary.html#MemoryVisibility

• A call to start on a thread happens-before any action in the started thread.

which along with the other effects listed:

• An unlock (synchronized block or method exit) of a monitor happens-before every subsequent lock (synchronized block or method entry) of that same monitor. And because the happens-before relation is transitive, all actions of a thread prior to unlocking happen-before all actions subsequent to any thread locking that monitor.

• A write to a volatile field happens-before every subsequent read of that same field. Writes and reads of volatile fields have similar memory consistency effects as entering and exiting monitors, but do not entail mutual exclusion locking.

so yes it has the same effects

The newly started thread will act as a memory barrier for that particular thread.

All other threads will have to synchronize the access ( by entering synchronized block or acquiring a lock ) to see the updated non-final non-volatile variables.