<div dir="ltr"><div>Ok that makes sense.<br></div><div><br></div><div>I measured the performance and no this is not close to being a bottleneck on the current setup, since there are other places which are much slower. So the initial question was more into the "lets experiment" side of things and learn. My thinking was that since we only have one writer and thats only on a specific interval (5 mins) there would be a waste of using the CHM to host the data. Taking a snapshot of the current state during a write, replace of things and reassign the map variable to the snapshot seemed more interesting.</div>
<div><br></div><div>Thanks again :)</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Nov 29, 2013 at 8:42 AM, Nitsan Wakart <span dir="ltr"><<a href="mailto:nitsanw@yahoo.com" target="_blank">nitsanw@yahoo.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-size:10pt;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif"><div>
<span>What could go wrong is:</span></div><div style="font-style:normal;font-size:13.600000381469727px;background-color:transparent;font-family:HelveticaNeue,'Helvetica Neue',Helvetica,Arial,'Lucida Grande',sans-serif">
<span>   while(getMap().get(key)){</span></div><div style="font-style:normal;font-size:13.600000381469727px;background-color:transparent;font-family:HelveticaNeue,'Helvetica Neue',Helvetica,Arial,'Lucida Grande',sans-serif">
<span>      // wait for key</span></div><div style="font-style:normal;font-size:13.600000381469727px;background-color:transparent;font-family:HelveticaNeue,'Helvetica Neue',Helvetica,Arial,'Lucida Grande',sans-serif">
<span> 
  }</span></div><div style="font-style:normal;font-size:13.600000381469727px;background-color:transparent;font-family:HelveticaNeue,'Helvetica Neue',Helvetica,Arial,'Lucida Grande',sans-serif"><span>Can in theory (and sometimes in practice) spin forever. The value gets hoisted and never checked again. The JIT assumes there's no way for the read value to change, so won't check again. At that point the 'at some point' becomes 'never'.</span></div>
<div style="font-style:normal;font-size:13.600000381469727px;background-color:transparent;font-family:HelveticaNeue,'Helvetica Neue',Helvetica,Arial,'Lucida Grande',sans-serif">Reading through your original post again I would take a step back and evaluate the performance win vs. correctness. Are you 100% sure this is a bottleneck for your program? have you tried and measured using CHM and it makes a measurable difference to use your
 alternative?</div><div style="font-style:normal;font-size:13.600000381469727px;background-color:transparent;font-family:HelveticaNeue,'Helvetica Neue',Helvetica,Arial,'Lucida Grande',sans-serif">If the answer to the above is "yes we did, and yes it does" then it would be good to see some concrete code to demonstrate how you are using this map.</div>
<div><div class="h5"><div style="display:block"> <br> <br> <div style="font-family:HelveticaNeue,'Helvetica Neue',Helvetica,Arial,'Lucida Grande',sans-serif;font-size:10pt"> <div style="font-family:HelveticaNeue,'Helvetica Neue',Helvetica,Arial,'Lucida Grande',sans-serif;font-size:12pt">
 <div dir="ltr"> <font face="Arial"> On Friday, November 29, 2013 10:01 AM, Thomas Kountis <<a href="mailto:tkountis@gmail.com" target="_blank">tkountis@gmail.com</a>> wrote:<br> </font> </div>  <div><div><div><div dir="ltr">
Thanks for the responses guys.<div>I do
 understand all the above, but what I don't understand is what could go wrong with the no barrier approach on x86 ? Wouldn't that write eventually get flushed to main memory, and the other processors must invalidate cache at some point also ? I know this is a lot of "at some point", therefore, I guess its very vague to be trusted, but is there anything else apart from timing that could go wrong and that write not become visible?</div>

<div><br clear="none"></div><div>t.</div><div><div><br clear="none"><br clear="none"><div>On Fri, Nov 29, 2013 at 6:51 AM, Nitsan Wakart <span dir="ltr"><<a rel="nofollow" shape="rect" href="mailto:nitsanw@yahoo.com" target="_blank">nitsanw@yahoo.com</a>></span> wrote:<br clear="none">

<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-size:10pt;font-family:HelveticaNeue,'Helvetica Neue',Helvetica,Arial,'Lucida Grande',sans-serif"><div>

<span>From my experience, lazySet is indeed your best choice (but only a valid choice for a single writer). You need a volatile read to match the HB relationship otherwise the compiler is free to optimize the value you read, so someone using your map in a loop may end up stuck if you don't do it.</span></div>

<div><div><div style="font-style:normal;font-size:13.600000381469727px;background-color:transparent;font-family:HelveticaNeue,'Helvetica Neue',Helvetica,Arial,'Lucida Grande',sans-serif"><br clear="none">
</div>
<div style="display:block"> <br clear="none"> <br clear="none"> <div style="font-family:HelveticaNeue,'Helvetica Neue',Helvetica,Arial,'Lucida Grande',sans-serif;font-size:10pt"> <div> <div dir="ltr"> <font face="Arial"> On Friday, November 29, 2013 5:35 AM, Vitaly Davidovich <<a rel="nofollow" shape="rect" href="mailto:vitalyd@gmail.com" target="_blank">vitalyd@gmail.com</a>> wrote:<br clear="none">

 </font> </div>  <div><div><div><div dir="ltr">AtomicReference.lazySet is the way to go here - on x86 this is just normal mov instruction with compiler barrier only (StoreStore).  If you don't want overhead of AtomicReference wrapper (doesn't sound like that would be an issue) you can get same effect with Unsafe.putObjectOrdered.</div>



<div dir="ltr">I wouldn't worry about AtomicReference.get() performance on x86 - this is a read from memory but if you read frequently, you'll hit L1 cache anyway.</div>
<div dir="ltr">HTH</div>
<div dir="ltr">Sent from my phone</div>
<div>On Nov 28, 2013 5:34 PM, "Thomas Kountis" <<a rel="nofollow" shape="rect" href="mailto:tkountis@gmail.com" target="_blank">tkountis@gmail.com</a>> wrote:<br clear="none"><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div><div dir="ltr">Hi all,<div><br clear="none"></div><div>This is my first time posting on this list, been follower for quite some time now and really enjoying all the knowledge sharing :) .</div><div><br clear="none">

</div><div>I was looking on optimizing a solution today at work, and I came across the following.</div>

<div>We have a scenario where we keep a simple cache (HashMap) and this is accessed by multiple</div><div>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).</div>



<div><br clear="none"></div><div>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?</div>



<div><br clear="none"></div><div>Any ideas, alternatives?</div><div><br clear="none"></div><div>PS. Sorry for the question-bombing :/</div><div><br clear="none"></div><div>Regards,</div><div>Thomas</div><div>
</div></div></div>
<br clear="none">_______________________________________________<br clear="none">
Concurrency-interest mailing list<br clear="none">
<a rel="nofollow" shape="rect" href="mailto:Concurrency-interest@cs.oswego.edu" target="_blank">Concurrency-interest@cs.oswego.edu</a><br clear="none">
<a rel="nofollow" shape="rect" href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><br clear="none">
<br clear="none"></blockquote></div></div></div><br clear="none"><div>_______________________________________________<br clear="none">Concurrency-interest mailing list<br clear="none"><a rel="nofollow" shape="rect" href="mailto:Concurrency-interest@cs.oswego.edu" target="_blank">Concurrency-interest@cs.oswego.edu</a><br clear="none">

<a rel="nofollow" shape="rect" href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><br clear="none"></div><br clear="none"><br clear="none">
</div>  </div> </div>  </div> </div>
</div></div></div></blockquote></div><br clear="none"><div><br clear="none"></div>
</div></div></div></div></div><br><br></div>  </div> </div>  </div> </div></div></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><font color="#444444">Thomas Kountis<br>PGP: 0x069D29A3</font><div>
<font color="#999999"><br></font></div><div><p style="margin:0px 0px 1em;padding:0px;border:0px;vertical-align:baseline;clear:both;word-wrap:break-word;font-family:Arial,'Liberation Sans','DejaVu Sans',sans-serif;line-height:18px">
<font size="1" color="#666666">Q: "Whats the object-oriented way to become wealthy?"<br>A:  Inheritance</font></p></div></div>
</div>