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

Oleksandr Otenko oleksandr.otenko at oracle.com
Fri Nov 29 09:23:15 EST 2013

How do you distinguish stale data from new data?

If, for example, you mean a new key should appear in HashMap (otherwise 
the new HashMap is a copy of the previous), then not using the volatile 
field can result in wrong order of the key becoming visible - the reader 
threads might already see the new reference, but not the new keys yet. 
The timing of the new keys appearing depends on how soon the writer gets 
to flush the write buffers. This may appear as "reading stale data".


On 28/11/2013 22:23, Thomas Kountis 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/20131129/0a7bd490/attachment.html>

More information about the Concurrency-interest mailing list