[concurrency-interest] Curious: How Java Memory Model is satisfied in JSR166 locks?

Jason T. Greene jason.greene at redhat.com
Tue Aug 21 10:04:11 EDT 2007


Compl Yue Still wrote:
> But to my understanding of the requirements of the Memory Model, upon
> a lock action all variable values must be flushed out of the thread's
> working memory, especially other variables not marked as volatile but
> ever read by current thread; and upon unlock, all assigned variables
> even not marked as volatile in the thread's working memory must be
> synchronized to the main memory. So if my understanding is correct so
> far, do you imply that accessing a volatile variable causes Hotspot to
> synchronize the thread's working memory with main memory? I'm doubting
> coz I havn't noticed this requirement in JLS.. Or this is specific to
> Hotspot VM?
> 

Yes volatile in JDK 5+ triggers a memory barrier.

-- 
Jason T. Greene
Lead, POJO Cache
JBoss, a division of Red Hat


More information about the Concurrency-interest mailing list