[concurrency-interest] Single writer multiple readers no barriers -- safe ?

Thomas Kountis tkountis at gmail.com
Thu Nov 28 17:23:45 EST 2013

Hi all,

This is my first time posting on this list, been follower for quite some
time now and really enjoying all the knowledge sharing :) .

I was looking on optimizing a solution today at work, and I came across the
We have a scenario where we keep a simple cache (HashMap) and this is
accessed by multiple
readers on an application server, millions of times per day and highly
contented. This cache is immutable and only gets updated by a single writer
by replacing the reference that the variable points to every 5 mins. This
is currently done as a volatile field. I was looking for a way to lose
completely the memory barriers and rely on that field being eventually
visible across all other threads (no problem by reading stale data for a
few seconds).

Would that be possible with the current JMM ? I tried to test that scenario
with some code, and it seems to work most of the times, but some threads
read stale data for longer that I would expect (lots of seconds). Is there
any platform dependency on such implementation ? Its going to run on x86
environments. Is there any assumption we can make as of how long that
'eventually' part can be ? (could it be more than 5 mins, when the next
write occurs?). My understanding is that, that write even if re-ordered
will have to happen. I came across an article about using the
AtomicReference doing a lazySet (store-store) for the write, and then the
Unsafe to do a getObject (direct) instead of the default get which is based
on the volatile access. Would that be a better solution?

Any ideas, alternatives?

PS. Sorry for the question-bombing :/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20131128/61e9f5c2/attachment.html>

More information about the Concurrency-interest mailing list