[concurrency-interest] when is safe publication safe?
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
> 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.
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
More information about the Concurrency-interest