Re: [hibernate-dev] HSEARCH-189 & concurrency

2008-07-05 Thread Emmanuel Bernard
On Jul 4, 2008, at 21:06, Sanne Grinovero wrote: 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

Re: [hibernate-dev] HSEARCH-189 & concurrency

2008-07-04 Thread Sanne Grinovero
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 cour

Re: [hibernate-dev] HSEARCH-189 & concurrency

2008-07-04 Thread Emmanuel Bernard
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 Sear

Re: [hibernate-dev] HSEARCH-189 & concurrency

2008-07-04 Thread Sanne Grinovero
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 T

Re: [hibernate-dev] HSEARCH-189 & concurrency

2008-07-04 Thread Pavitar Singh
Hi Emmanuel, Piggybacking on Synchronization is documented by Brian Goetz in Java Concurrency In Practice section 16.1.4 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 synchr

Re: [hibernate-dev] HSEARCH-189 & concurrency

2008-07-04 Thread Emmanuel Bernard
Doh I need System.Threading.Thread.MemoryBarrier() but in Java :( -- 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 16:26, Emmanuel Bernard wrote:

Re: [hibernate-dev] HSEARCH-189 & concurrency

2008-07-04 Thread Emmanuel Bernard
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 HSe

Re: [hibernate-dev] HSEARCH-189 & concurrency

2008-07-04 Thread Sanne Grinovero
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-w

[hibernate-dev] HSEARCH-189 & concurrency

2008-07-03 Thread Sanne Grinovero
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 FSSlaveDirectoryPr