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

Martin Buchholz martinrb at google.com
Thu Nov 28 18:06:39 EST 2013

You have one thread writing to the HashMap and another thread reading it,
so there needs to be some kind of safe publication ("memory barrier" -
which might end up being a no-op in the hardware) in between somewhere.  A
volatile HashMap field sounds good to me.

On Thu, Nov 28, 2013 at 2:23 PM, Thomas Kountis <tkountis at gmail.com> wrote:

> 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 following.
> 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 :/
> Regards,
> Thomas
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20131128/7ca10a26/attachment.html>

More information about the Concurrency-interest mailing list