[concurrency-interest] when is safe publication safe?

Jochen Theodorou blackdrag at gmx.org
Mon Apr 26 17:05:29 EDT 2010

Taylor Gautier wrote:
> This is very interesting. What you have here are read many, write 
> infrequently, but writes must be coherent for readers but once 
> 'refreshed' readers shouldn't incur barrier penalties.  

Mostly, yes. I think I can live with some incoherences, but it would be 
more easy without them. But of course, it should not happen that one 
modification of a metaclass is visible, while another one on the same 
metaclass done before is not. Also two meta classes modified by one 
thread and only one of them becoming visible in the other might not be 
so good. So maybe it really does have to be coherent.

> Terracotta solves this problem at the network level for many jvms by 
> allowing local readers and writers to acquire a lock with a lock lease 
> which can be revoked asynchronously.  This allows local jvms to proceed 
> with a read lock without incurring a lock read penalty.   I mention 
> Terracotta because  for this problem JVMs in a cluster are analogous to 
> threads in the JVM. 

How does Terracotta perform if the code uses a lot of locks? I did hear 
it is not so well.

> Is it possible to construct the same thing in threads using java 
> primitives? 
> Does a ReentrantReadWriteLock help? I don't think so. What you would 
> need is for all threads to acquire and hold a read lock but have an 
> ability to acquiesce it on demand for a writer without incurring memory 
> barrier hits.   
> I can't think of any way to 'cache' a read lock in ThreadLocal such that 
> it doesn't incur barriers on every read and yet also can yield to a 
> writer asynchronously. 

additionally has the data leak problem. Since there is no defined entry 
and exit point I can use, I cannot remove the stored ThreadLocal data 
the correct way. Well I can, but then the caching would cost more than 
what I wanted to cache.

bye Jochen

Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)

More information about the Concurrency-interest mailing list