On Fri, Oct 29, 2010 at 11:01 AM, Charles Forsyth <[email protected]> wrote: >>What you are saying is that the problem could be something like: > >>-> Tclunk >>(do not wait for response) >>-> Topen (the file is exclusive) > > no, because what actually happens is closer to > A: Topen > ... > queue request to *another process* to send Tclunk > ... > A: Topen > > leading to either case 1 > A: Topen > B: Tclunk > A: Topen > > or case 2 > A: Topen > A: Topen > B: Tclunk > > depending on the scheduling of the two processes A and B > > introducing that other process introduces a new race, that simply did not > exist before, because > that other process didn't exist before. you always got case 1. > > and indeed, with the test i ran on the modified system usually it gets case 1 > because of timing, but eventually a case 2 shows up and the second open fails. > >
That is why I said, (my second message in the thread) that at least you should send the Tclunks synchronously. Meaning the close system call sends the Tclunk and then fires another thread/writes down in a list for another thread for the fid to be recollected when the answer comes asynchronously. This prevents the fid being reused and simultaneously tries to keep the operations in the order the client intended. Still there are no guarantees, because the messages can be reordered in the server but... Still, it does not work in general (the server...) and I thought it was not profitable enough to be worth the hassle, but then... > my froggie has been running for four years 24/7. if you haven't read > the BLTJ then styx runs over the PCI ... 4 ixp1200s. asynch clunks. > the only problem is it's 10 times quicker. I haven´t read the Journal, I thought it was referring to the Dylan´s song putting froggie as an archetype of decency. You are talking about this?: http://onlinelibrary.wiley.com/doi/10.1002/bltj.1/pdf Do you do completely asynch clunks or just the wait for the response?. 10 times?, that is some latency. Can you break up exactly where the gain comes from?. G.
