Hi Pavitar Singh, I thank you very much about your explanations but actually I opened the issue myself because I have read the same specs and am aware of that. in H.Search (and several other hibernate code) there's this quite common pattern for starting "replaceable" objects (something like user-written plugins, you can provide your own implementation to do some stuff) but this same pattern is also used to start the built-in default strategies. It looks like this: - an empty constructor, to use class.newInstance(); - an initialize() to set configuration options - a start() method (eventually) used to start background tasks - some doStuff() and/or getXX() which need to be fast & threadsafe As you can see in Concurrecy in Practice at page 50, this is BAD, as for example in the FSSlaveDirectoryProvider nobody takes care of locking or visibility, and nobody is doing anywhere where I see this pattern used (several times in the project). I'm not saying it is all broken, because usually the threads consuming these unsafely-initialized objects are started after the initialization, so that's ok. In this specific case the state will be used to communicate between threads, so some visibility fix is needed. I know I could use it only for final fields, but this is exactly what I want: there are currently 10 instance variables, of these 4 have no concurrent use 4 are configuration constants and could use the "final" (they're not safely published) 2 would need some lock/volatile anyway, bot only one is used frequently, so IMHO 1 volatile is ok. I was thinking in using the same Piggyback technique you mention to safely publish the initialization constants, but I'm afraid the code will become more difficult to maintain and more "unreadable", possibly breaking at the first next patch: IMHO using some unchanging fields "final" is the most clean and readable solution (and best performing), but I need a different constructor for that. your opinion is really welcome as I couldn't find other feedback, if you would like to take a look at the sources download the Search trunk and look at: org.hibernate.search.store.FSSlaveDirectoryProvider or the FIXME in org.hibernate.search.reader.SharingBufferReaderProvider Sanne 2008/7/4 Pavitar Singh <pavitar.singh(a)gmail.com&gt;: Hi Sanne, I don't think moving everything in constructor can guarantee safe publication. From the JMM Specification Section 3.5 "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." That means there are no guarantees for other fields which are non- final. But once things are moved in constructor then by using Safe Publication one can enforce visibility guarantees. 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.) 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. Regards Pavitar Singh http://pitfalls.wordpress.com On Fri, Jul 4, 2008 at 5:13 AM, Sanne Grinovero <sanne.grinovero(a)gmail.com > wrote: Hello all, I'm sorry I've been very busy but as promised I would like to fix HSEARCH-189 (and others) very soon; I would like to propose a API extension (backwards compatible) that would simplify the patch a lot: keeping it as is it is very tricky to fix the visibility issues in FSSlaveDirectoryProvider and FSMasterDirectoryProvider without introducing a performance penalty. I have these options to close the issue: 1) add a "volatile" to more than six fields per class (ugly and not good for performance) 2) use some Locks/synch (more readable, still performance hits) 3) move the "initialize" arguments to a constructor. As Emmanuel knows I would really love the third option, but he's worried about the fact we can't force a constructor in an interface*1, so my proposal is: if we find there exists a constructor having the same arguments as the initialize method, we use that, otherwise we use a no-arg constructor and then call the initialize. Reflection is used anyway to instantiate these components, the code in DirectoryProviderFactory doesn't get much more complicated and much more cleanup is made possible in all DPs because of this (as the equals/hashcode comments already ask for). I actually think this same pattern is needed for other components, such as all ReaderProvider, so I hope you'll want to give it a try and let me apply it on other components too if you like the resulting code. Sanne _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev -- Pavitar Singh Blog: http://pitfalls.wordpress.com _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Hey,Can you tell me more about the piggyback synchronization. I could not find any decent knowledge online. how far reading a volatile guarantee that all "local" values of the thread we are reading from will be pushed to the shared memory? 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? 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. -- Emmanuel Bernard http://in.relation.to/Bloggers/Emmanuel | http://blog.emmanuelbernard.com| http://twitter.com/emmanuelbernard Hibernate Search in Action (http://is.gd/Dl1) On Jul 4, 2008, at 04:33, Sanne Grinovero wrote: Hi Pavitar Singh, I thank you very much about your explanations but actually I opened the issue myself because I have read the same specs and am aware of that. in H.Search (and several other hibernate code) there's this quite common pattern for starting "replaceable" objects (something like user-written plugins, you can provide your own implementation to do some stuff) but this same pattern is also used to start the built-in default strategies. It looks like this: - an empty constructor, to use class.newInstance(); - an initialize() to set configuration options - a start() method (eventually) used to start background tasks - some doStuff() and/or getXX() which need to be fast & threadsafe As you can see in Concurrecy in Practice at page 50, this is BAD, as for example in the FSSlaveDirectoryProvider nobody takes care of locking or visibility, and nobody is doing anywhere where I see this pattern used (several times in the project). I'm not saying it is all broken, because usually the threads consuming these unsafely-initialized objects are started after the initialization, so that's ok. In this specific case the state will be used to communicate between threads, so some visibility fix is needed. I know I could use it only for final fields, but this is exactly what I want: there are currently 10 instance variables, of these 4 have no concurrent use 4 are configuration constants and could use the "final" (they're not safely published) 2 would need some lock/volatile anyway, bot only one is used frequently, so IMHO 1 volatile is ok. I was thinking in using the same Piggyback technique you mention to safely publish the initialization constants, but I'm afraid the code will become more difficult to maintain and more "unreadable", possibly breaking at the first next patch: IMHO using some unchanging fields "final" is the most clean and readable solution (and best performing), but I need a different constructor for that. your opinion is really welcome as I couldn't find other feedback, if you would like to take a look at the sources download the Search trunk and look at: org.hibernate.search.store.FSSlaveDirectoryProvider or the FIXME in org.hibernate.search.reader.SharingBufferReaderProvider Sanne 2008/7/4 Pavitar Singh <pavitar.singh(a)gmail.com&gt;: > Hi Sanne, > > I don't think moving everything in constructor can guarantee safe > publication. > > From the JMM Specification Section 3.5 > > "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." > > That means there are no guarantees for other fields which are non-final. > > But once things are moved in constructor then by using Safe Publication > one can enforce visibility guarantees. > > 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.) > > 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. > > Regards > Pavitar Singh > http://pitfalls.wordpress.com > > On Fri, Jul 4, 2008 at 5:13 AM, Sanne Grinovero < > sanne.grinovero(a)gmail.com&gt; wrote: > >> Hello all, >> I'm sorry I've been very busy but as promised I would like to fix >> HSEARCH-189 >> (and others) very soon; >> >> I would like to propose a API extension (backwards compatible) that would >> simplify the patch a lot: >> keeping it as is it is very tricky to fix the visibility issues in >> FSSlaveDirectoryProvider >> and FSMasterDirectoryProvider without introducing a performance penalty. >> >> I have these options to close the issue: >> 1) add a "volatile" to more than six fields per class (ugly and not good >> for performance) >> 2) use some Locks/synch (more readable, still performance hits) >> 3) move the "initialize" arguments to a constructor. >> >> As Emmanuel knows I would really love the third option, but he's worried >> about >> the fact we can't force a constructor in an interface*1, so my proposal >> is: >> >> if we find there exists a constructor having the same arguments as the >> initialize method, >> we use that, otherwise we use a no-arg constructor and then call the >> initialize. >> >> Reflection is used anyway to instantiate these components, >> the code in DirectoryProviderFactory doesn't get much more complicated >> and much more cleanup is made possible in all DPs because of this >> (as the equals/hashcode comments already ask for). >> >> I actually think this same pattern is needed for other components, >> such as all ReaderProvider, so I hope you'll want to give it a try >> and let me apply it on other components too if you like the resulting >> code. >> >> Sanne >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> > > > -- > Pavitar Singh > Blog: http://pitfalls.wordpress.com _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Thanks for your blog Pavitar; I would like to add some clarification about the "piggyback" just to confirm: there is no such concept as "THE shared memory" in the JMM, shared memory is about memory shared between some threads, not necessarily all. the "piggyback" trick works basing on this: after ThreadB reads a volatile variable, it is guaranteed to see at least ALL state TrheadA had written before (and during) a write to THAT SAME volatile variable. Note the "at least" wording: more changes could happen to the other variables after the write to the volatile, and some (in no order, especially not the code order) could be also seen, but no guarantee about. so you could: write field1, field2, field3 and then the volatile field4 in T1 read volatile field4, field1, field2, field3 in T2 (after T1 did) and you will get a guarantee that T2 will "see" at least the state written by T1. So this is a "trick" to avoid longer locks or having to convert them all to volatile, but IMHO the code is made difficult to maintain, and tricky to get it right. In our practical case: you could write to some volatile field in the SearchFactoryImpl after the initialization is done, but then you still have to ensure all subsequent uses will read the same field before anything else; this has a minimal impact on performance, the good think about the "piggyback" is you could use a read to a volatile you would have anyway. I don't think this is at all needed for the SearchFactoryImpl as long as you guarantee that the threads going to use it are started ("start()") after and by the initialization thread; if this is correct no further discussion is needed there. In the readeProviders and DPProviders I can't get this guarantee, that's why they need a fix. Shall I use this trick then? It isn't so bad if you think it's accepatable to use it, it's good for performance but I dislike it for code readability; I'll add a big fat scary warning. IMHO this should be avoided when possible, especially since "final" works fine and is very explicit to another code reader. If you think I should go for the pig, I would appreciate if Pavitar could read the code after I commit it to check my code, even if this case is trivial. Sanne 2008/7/4 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: Hey, Can you tell me more about the piggyback synchronization. I could not find any decent knowledge online. how far reading a volatile guarantee that all "local" values of the thread we are reading from will be pushed to the shared memory? 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? 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. -- Emmanuel Bernard http://in.relation.to/Bloggers/Emmanuel | http://blog.emmanuelbernard.com | http://twitter.com/emmanuelbernard Hibernate Search in Action (http://is.gd/Dl1) On Jul 4, 2008, at 04:33, Sanne Grinovero wrote: > Hi Pavitar Singh, > > I thank you very much about your explanations but actually I opened > the issue myself > because I have read the same specs and am aware of that. > in H.Search (and several other hibernate code) there's this quite > common pattern for starting > "replaceable" objects (something like user-written plugins, you can > provide your own implementation > to do some stuff) but this same pattern is also used to start the > built-in default strategies. > > It looks like this: > - an empty constructor, to use class.newInstance(); > - an initialize() to set configuration options > - a start() method (eventually) used to start background tasks > - some doStuff() and/or getXX() which need to be fast & threadsafe > > As you can see in Concurrecy in Practice at page 50, this is BAD, > as for > example in the FSSlaveDirectoryProvider nobody takes care of locking > or visibility, and nobody is doing anywhere where I see this > pattern used > (several times in the project). > I'm not saying it is all broken, because usually the threads > consuming > these unsafely-initialized objects are started after the > initialization, so > that's ok. In this specific case the state will be used to > communicate > between threads, so some visibility fix is needed. > > I know I could use it only for final fields, but this is exactly > what I want: > there are currently 10 instance variables, of these > 4 have no concurrent use > 4 are configuration constants and could use the "final" (they're > not safely published) > 2 would need some lock/volatile anyway, bot only one is used > frequently, so IMHO 1 volatile is ok. > > I was thinking in using the same Piggyback technique you mention to > safely publish the initialization constants, > but I'm afraid the code will become more difficult to maintain and > more > "unreadable", possibly breaking at the first next patch: > IMHO using some unchanging fields "final" is the most clean and > readable solution (and best performing), but I need a different > constructor for that. > > your opinion is really welcome as I couldn't find other feedback, > if you would like to take a look at the sources download the Search > trunk > and look at: > org.hibernate.search.store.FSSlaveDirectoryProvider > or the FIXME in > org.hibernate.search.reader.SharingBufferReaderProvider > > Sanne > > 2008/7/4 Pavitar Singh <pavitar.singh(a)gmail.com&gt;: > Hi Sanne, > > I don't think moving everything in constructor can guarantee safe > publication. > > From the JMM Specification Section 3.5 > > "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." > > That means there are no guarantees for other fields which are non- > final. > > But once things are moved in constructor then by using Safe > Publication one can enforce visibility guarantees. > > 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.) > > 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. > > Regards > Pavitar Singh > http://pitfalls.wordpress.com > > On Fri, Jul 4, 2008 at 5:13 AM, Sanne Grinovero <sanne.grinovero(a)gmail.com > > wrote: > Hello all, > I'm sorry I've been very busy but as promised I would like to fix > HSEARCH-189 > (and others) very soon; > > I would like to propose a API extension (backwards compatible) that > would simplify the patch a lot: > keeping it as is it is very tricky to fix the visibility issues in > FSSlaveDirectoryProvider > and FSMasterDirectoryProvider without introducing a performance > penalty. > > I have these options to close the issue: > 1) add a "volatile" to more than six fields per class (ugly and not > good for performance) > 2) use some Locks/synch (more readable, still performance hits) > 3) move the "initialize" arguments to a constructor. > > As Emmanuel knows I would really love the third option, but he's > worried about > the fact we can't force a constructor in an interface*1, so my > proposal is: > > if we find there exists a constructor having the same arguments as > the initialize method, > we use that, otherwise we use a no-arg constructor and then call > the initialize. > > Reflection is used anyway to instantiate these components, > the code in DirectoryProviderFactory doesn't get much more > complicated > and much more cleanup is made possible in all DPs because of this > (as the equals/hashcode comments already ask for). > > I actually think this same pattern is needed for other components, > such as all ReaderProvider, so I hope you'll want to give it a try > and let me apply it on other components too if you like the > resulting code. > > Sanne > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > -- > Pavitar Singh > Blog: http://pitfalls.wordpress.com > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev

Yes what you formalized is exactly what I meant; there's an additional point in the "piggyback" strategy, which is to actually use some volatile read (or any other memorybarrier) which you couldn't avoid anyway, to avoid the cost of reading a volatile. No need to make it excessively complex of course, but if we could reuse some other barrier it would just come free. This is also the drawback if it is not properly commented: the code would completely hide the fact it is providing some memory barrier idiom, it could look- like you are aquiring some lock you need or read some needed field and forget to synch some more data. What I mean with the "readeProviders and DPProviders" issue is that I am sure I need to do something like this. You just told me I can't trust the SearchFactory initialization: "(especially Containers can do stupid things)", I didn't know that and I wasn't sure we had a problem with initialization too; I'll rewrite my opinion as "don't know if it's needed with Search initialization as I don't know how that happens, but I'm quite sure we need some more locking in ReadeProviders and DPProviders". After reading your post I think we concluded we need it everywhere; IMHO a good candidate to become volatile is "protected SearchFactoryImplementor searchFactoryImplementor" in FullTextIndexEventListener, but it will hurt performance, even if minimal; if we could replace that initialize with a similar constructor it would be "free" as in Zurich's beer.

This would involve an "extension" in the Hibernate listeners initialization, but as you are releasing a new version it shouldn't be much of a problem?

I could commit my proposed fix for the ReadeProviders and DPProviders, so you can look at it and get an idea of the little change: there's just and happen-once reflection usage to see if an appropriate constructor is available to be used as replacement for initialize();

Also if you look at the work I had done on SearchFactoryImpl you'll notice that just 2 fields are not final yet, I converted most already. Sanne 2008/7/5 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: Hibernate Search cannot guarantee that threads using the SearchFActory have been started after the thread initializing the SearchFactory (especially Containers can do stupid things). So you need to do someting like that: SF.init() { ... myvolatile++; //write } and upon access to the SearchFactory //note the thread local variable is per search factory instance if ( searchFactory.getThreadLocalCheck().get() == null) { //note the thread local variable is per search factory instance boolean checked = myVolatile != 0; searchFactory.getThreadLocalCheck().put(checked); } If I understand correctly, this ensures that any threat Tn will see what Ti (the initialization thread) has written by acquiring the "lock" only once. (this is the formalization of what you proposed in Zurich). Someone corrects me if I'm wrong. But you scare me with "In the readeProviders and DPProviders I can't get this guarantee". What do you mean? initialize and start are always called before the SearchFactory initialization ends. I don't see the code being that scary, the sync issue is dealt by the framework without exposing the user to the "piggy" details. -- Emmanuel Bernard http://in.relation.to/Bloggers/Emmanuel | http://blog.emmanuelbernard.com | http://twitter.com/emmanuelbernard Hibernate Search in Action (http://is.gd/Dl1) On Jul 4, 2008, at 18:36, Sanne Grinovero wrote: > Thanks for your blog Pavitar; > I would like to add some clarification about the "piggyback" just > to confirm: > there is no such concept as "THE shared memory" in the JMM, shared > memory is about memory shared between some threads, not necessarily > all. > the "piggyback" trick works basing on this: after ThreadB reads a > volatile variable, it is guaranteed to see at least ALL state > TrheadA had written before (and during) > a write to THAT SAME volatile variable. Note the "at least" > wording: more changes could happen to the other variables after the > write to the volatile, and some (in no order, > especially not the code order) could be also seen, but no guarantee > about. > so you could: > write field1, field2, field3 and then the volatile field4 in T1 > read volatile field4, field1, field2, field3 in T2 (after T1 did) > and you will get a guarantee that T2 will "see" at least the state > written by T1. > > So this is a "trick" to avoid longer locks or having to convert > them all to volatile, but IMHO > the code is made difficult to maintain, and tricky to get it right. > > In our practical case: > you could write to some volatile field in the SearchFactoryImpl > after the initialization is done, > but then you still have to ensure all subsequent uses will read the > same field before anything else; > this has a minimal impact on performance, the good think about the > "piggyback" is you > could use a read to a volatile you would have anyway. > I don't think this is at all needed for the SearchFactoryImpl as > long as you guarantee that > the threads going to use it are started ("start()") after and by > the initialization thread; > if this is correct no further discussion is needed there. > In the readeProviders and DPProviders I can't get this guarantee, > that's why they need a fix. > > Shall I use this trick then? It isn't so bad if you think it's > accepatable to use it, it's good for performance > but I dislike it for code readability; I'll add a big fat scary > warning. > IMHO this should be avoided when possible, especially since "final" > works fine and is > very explicit to another code reader. > > If you think I should go for the pig, I would appreciate if Pavitar > could read the code after I commit it > to check my code, even if this case is trivial. > > Sanne > > 2008/7/4 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: > Hey, > Can you tell me more about the piggyback synchronization. I could > not find any decent knowledge online. > how far reading a volatile guarantee that all "local" values of the > thread we are reading from will be pushed to the shared memory? > 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? > 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. > > -- > Emmanuel Bernard > http://in.relation.to/Bloggers/Emmanuel | http://blog.emmanuelbernard.com > | http://twitter.com/emmanuelbernard > Hibernate Search in Action (http://is.gd/Dl1) > > On Jul 4, 2008, at 04:33, Sanne Grinovero wrote: > >> Hi Pavitar Singh, >> >> I thank you very much about your explanations but actually I >> opened the issue myself >> because I have read the same specs and am aware of that. >> in H.Search (and several other hibernate code) there's this quite >> common pattern for starting >> "replaceable" objects (something like user-written plugins, you >> can provide your own implementation >> to do some stuff) but this same pattern is also used to start the >> built-in default strategies. >> >> It looks like this: >> - an empty constructor, to use class.newInstance(); >> - an initialize() to set configuration options >> - a start() method (eventually) used to start background tasks >> - some doStuff() and/or getXX() which need to be fast & threadsafe >> >> As you can see in Concurrecy in Practice at page 50, this is BAD, >> as for >> example in the FSSlaveDirectoryProvider nobody takes care of locking >> or visibility, and nobody is doing anywhere where I see this >> pattern used >> (several times in the project). >> I'm not saying it is all broken, because usually the threads >> consuming >> these unsafely-initialized objects are started after the >> initialization, so >> that's ok. In this specific case the state will be used to >> communicate >> between threads, so some visibility fix is needed. >> >> I know I could use it only for final fields, but this is exactly >> what I want: >> there are currently 10 instance variables, of these >> 4 have no concurrent use >> 4 are configuration constants and could use the "final" (they're >> not safely published) >> 2 would need some lock/volatile anyway, bot only one is used >> frequently, so IMHO 1 volatile is ok. >> >> I was thinking in using the same Piggyback technique you mention to >> safely publish the initialization constants, >> but I'm afraid the code will become more difficult to maintain and >> more >> "unreadable", possibly breaking at the first next patch: >> IMHO using some unchanging fields "final" is the most clean and >> readable solution (and best performing), but I need a different >> constructor for that. >> >> your opinion is really welcome as I couldn't find other feedback, >> if you would like to take a look at the sources download the >> Search trunk >> and look at: >> org.hibernate.search.store.FSSlaveDirectoryProvider >> or the FIXME in >> org.hibernate.search.reader.SharingBufferReaderProvider >> >> Sanne >> >> 2008/7/4 Pavitar Singh <pavitar.singh(a)gmail.com&gt;: >> Hi Sanne, >> >> I don't think moving everything in constructor can guarantee safe >> publication. >> >> From the JMM Specification Section 3.5 >> >> "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." >> >> That means there are no guarantees for other fields which are non- >> final. >> >> But once things are moved in constructor then by using Safe >> Publication one can enforce visibility guarantees. >> >> 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.) >> >> 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. >> >> Regards >> Pavitar Singh >> http://pitfalls.wordpress.com >> >> On Fri, Jul 4, 2008 at 5:13 AM, Sanne Grinovero <sanne.grinovero(a)gmail.com >> > wrote: >> Hello all, >> I'm sorry I've been very busy but as promised I would like to fix >> HSEARCH-189 >> (and others) very soon; >> >> I would like to propose a API extension (backwards compatible) >> that would simplify the patch a lot: >> keeping it as is it is very tricky to fix the visibility issues in >> FSSlaveDirectoryProvider >> and FSMasterDirectoryProvider without introducing a performance >> penalty. >> >> I have these options to close the issue: >> 1) add a "volatile" to more than six fields per class (ugly and >> not good for performance) >> 2) use some Locks/synch (more readable, still performance hits) >> 3) move the "initialize" arguments to a constructor. >> >> As Emmanuel knows I would really love the third option, but he's >> worried about >> the fact we can't force a constructor in an interface*1, so my >> proposal is: >> >> if we find there exists a constructor having the same arguments as >> the initialize method, >> we use that, otherwise we use a no-arg constructor and then call >> the initialize. >> >> Reflection is used anyway to instantiate these components, >> the code in DirectoryProviderFactory doesn't get much more >> complicated >> and much more cleanup is made possible in all DPs because of this >> (as the equals/hashcode comments already ask for). >> >> I actually think this same pattern is needed for other components, >> such as all ReaderProvider, so I hope you'll want to give it a try >> and let me apply it on other components too if you like the >> resulting code. >> >> Sanne >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> >> >> -- >> Pavitar Singh >> Blog: http://pitfalls.wordpress.com >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >