Hi Emmanuel,<br><br>Piggybacking on Synchronization is documented by Brian Goetz in Java Concurrency In Practice section 16.1.4<br><br>Basically what it means is one can piggyback on visiblity properties of existing synchronization(or volatile write).And other variables which are not guarded by any such synchronization will also be flushed to shared memory.But in this technique one needs to ensure ordering of statement execution prior to lock release or volatile write.But also at the same time its Guaranteed by JMM that ordering wont be changed for any non volatile variables writes happening before volatile write.So its safe to use this technique to ensure visibility guarantees in this case.<br>
<br>Similar technique is used in AQS in Future Task. I have written a blog entry about the powers given to volatile variables by JMM here <a href="http://pitfalls.wordpress.com/2008/05/25/javavolatile/">http://pitfalls.wordpress.com/2008/05/25/javavolatile/</a><br>
<br>So Answer to your questions is Yes. A write to volatile variable will flush everything to main memory.And it will be visible to all cases where first we do volatile read as that will enforce loading from main memory.<br>
<br>Regards<br>Pavitar<br><br><br><br><div class="gmail_quote">On Sat, Jul 5, 2008 at 1:56 AM, Emmanuel Bernard <<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style="">Hey,<div>Can you tell me more about the piggyback synchronization. I could not find any decent knowledge online.</div><div>how far reading a volatile guarantee that all "local" values of the thread we are reading from will be pushed to the shared memory?</div>
<div>For example, could reading a volatile value after HSearch is done with initialization (all init is done in a single thread) guarantee that all states held by this thead will be pushed back to the shared memory?</div>
<div>The use case is quite specific, I init everything in a single thread, want to push all the state to the shared memory. I know post init() use of HSearch will never change the state so I don't "need" locking.</div>
<div><br></div><div><font color="#888888"><div> <span style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><div style="">
<span style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><div style="">
<span style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><div style="">
<span style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><div style="">
<span style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><div style="">
<div>--</div><div>Emmanuel Bernard</div><div><a href="http://in.relation.to/Bloggers/Emmanuel" target="_blank">http://in.relation.to/Bloggers/Emmanuel</a> | <a href="http://blog.emmanuelbernard.com" target="_blank">http://blog.emmanuelbernard.com</a> | <a href="http://twitter.com/emmanuelbernard" target="_blank">http://twitter.com/emmanuelbernard</a></div>
<div>Hibernate Search in Action (<a href="http://is.gd/Dl1" target="_blank">http://is.gd/Dl1</a>)</div></div></span></div></span></div></span></div></span></div></span> </div></font><div><div></div><div class="Wj3C7c"><br>
<div><div>On Jul 4, 2008, at 04:33, Sanne Grinovero wrote:</div><br><blockquote type="cite">Hi Pavitar Singh,<br><br>I thank you very much about your explanations but actually I opened the issue myself<br>because I have read the same specs and am aware of that.<br>
in H.Search (and several other hibernate code) there's this quite common pattern for starting<br> "replaceable" objects (something like user-written plugins, you can provide your own implementation<br>to do some stuff) but this same pattern is also used to start the built-in default strategies.<br>
<br>It looks like this:<br> - an empty constructor, to use class.newInstance();<br>- an initialize() to set configuration options<br>- a start() method (eventually) used to start background tasks<br>- some doStuff() and/or getXX() which need to be fast & threadsafe<br>
<br>As you can see in Concurrecy in Practice at page 50, this is BAD, as for<br>example in the FSSlaveDirectoryProvider nobody takes care of locking<br>or visibility, and nobody is doing anywhere where I see this pattern used<br>
(several times in the project).<br>I'm not saying it is all broken, because usually the threads consuming<br>these unsafely-initialized objects are started after the initialization, so<br>that's ok. In this specific case the state will be used to communicate<br>
between threads, so some visibility fix is needed.<br><br>I know I could use it only for final fields, but this is exactly what I want:<br>there are currently 10 instance variables, of these<br>4 have no concurrent use<br>
4 are configuration constants and could use the "final" (they're not safely published)<br>2 would need some lock/volatile anyway, bot only one is used frequently, so IMHO 1 volatile is ok.<br><br>I was thinking in using the same Piggyback technique you mention to<br>
safely publish the initialization constants,<br>but I'm afraid the code will become more difficult to maintain and more<br>"unreadable", possibly breaking at the first next patch:<br>IMHO using some unchanging fields "final" is the most clean and<br>
readable solution (and best performing), but I need a different<br>constructor for that.<br><br>your opinion is really welcome as I couldn't find other feedback,<br>if you would like to take a look at the sources download the Search trunk<br>
and look at:<br>org.hibernate.search.store.FSSlaveDirectoryProvider<br>or the FIXME in <br>org.hibernate.search.reader.SharingBufferReaderProvider<br><br>Sanne<br><br><div class="gmail_quote">2008/7/4 Pavitar Singh <<a href="mailto:pavitar.singh@gmail.com" target="_blank">pavitar.singh@gmail.com</a>>:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi Sanne,<br><br>I don't think moving everything in constructor can guarantee safe publication.<br>
<br>From the JMM Specification Section 3.5<br><br>"An object is considered to be completely initialized when its constructor finishes. A thread that can only see a reference to an object after that object has been completely initialized is guaranteed to see the correctly initialized values for that object's final fields."<br>
<br>That means there are no guarantees for other fields which are non-final.<br><br>But once things are moved in constructor then by using Safe Publication one can enforce visibility guarantees.<br><br>Other thing i was wondering was why do one need to make every field as volatile. As just by using a single volatile variable one can enforce memory barriers. A technique documented in JCIP as Piggyback Synchronizations and used by Doug Lea in implementing ConcurrentHashMap.(You will find get method in ConcurrentHashMap is without any locking and visibility is enforced by use of a single volatile variable.)<br>
<br>Also if you can elaborate more on how you are facing the visibility issue then may be i can also spend time on it on figuring performant solution.<br><br>Regards<br>Pavitar Singh<br><a href="http://pitfalls.wordpress.com" target="_blank">http://pitfalls.wordpress.com</a><br>
<br><div class="gmail_quote"><div><div></div><div>On Fri, Jul 4, 2008 at 5:13 AM, Sanne Grinovero <<a href="mailto:sanne.grinovero@gmail.com" target="_blank">sanne.grinovero@gmail.com</a>> wrote:<br> </div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div> Hello all,<br>I'm sorry I've been very busy but as promised I would like to fix HSEARCH-189<br>(and others) very soon;<br><br>I would like to propose a API extension (backwards compatible) that would simplify the patch a lot:<br>
keeping it as is it is very tricky to fix the visibility issues in FSSlaveDirectoryProvider<br>and FSMasterDirectoryProvider without introducing a performance penalty.<br><br>I have these options to close the issue:<br>1) add a "volatile" to more than six fields per class (ugly and not good for performance)<br>
2) use some Locks/synch (more readable, still performance hits)<br>3) move the "initialize" arguments to a constructor.<br><br>As Emmanuel knows I would really love the third option, but he's worried about<br>
the fact we can't force a constructor in an interface*1, so my proposal is:<br><br>if we find there exists a constructor having the same arguments as the initialize method,<br>we use that, otherwise we use a no-arg constructor and then call the initialize.<br>
<br>Reflection is used anyway to instantiate these components,<br>the code in DirectoryProviderFactory doesn't get much more complicated<br>and much more cleanup is made possible in all DPs because of this<br>(as the equals/hashcode comments already ask for).<br>
<br>I actually think this same pattern is needed for other components,<br>such as all ReaderProvider, so I hope you'll want to give it a try<br>and let me apply it on other components too if you like the resulting code.<br>
<font color="#888888"> <br>Sanne<br> </font><br></div></div>_______________________________________________<br> hibernate-dev mailing list<br> <a href="mailto:hibernate-dev@lists.jboss.org" target="_blank">hibernate-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/hibernate-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/hibernate-dev</a><br> <br></blockquote></div><font color="#888888"><br><br clear="all"><br>-- <br>
Pavitar Singh<br>Blog: <a href="http://pitfalls.wordpress.com" target="_blank">http://pitfalls.wordpress.com</a> </font></blockquote></div><br> _______________________________________________<br>hibernate-dev mailing list<br>
<a href="mailto:hibernate-dev@lists.jboss.org" target="_blank">hibernate-dev@lists.jboss.org</a><br><a href="https://lists.jboss.org/mailman/listinfo/hibernate-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/hibernate-dev</a><br>
</blockquote></div><br></div></div></div></div></blockquote></div><br><br clear="all"><br>-- <br>Pavitar Singh<br>Blog: <a href="http://pitfalls.wordpress.com">http://pitfalls.wordpress.com</a>