Hi Rene and Anton, Thank you both very much for your responses. Rene Brun wrote: > > I could implement the following algorithm; > When the writer needs to update the directory (add/remove a key), it creates > first > a lock file (name =filename.lock) and deletes this file when the operation > is terminated. > When the reader calls ReadKeys, this function checks if the lock file exists. > If not it can go ahead, else it waits (using a TTimer). > A completly safe solution would imply a lockWrite file by the writer > and a lockRead file by the reader. > As usual comments are welcome. > This sounds like a good approach. I have the following comments though: 1)Since safety against crashes is a high priority for both the DAQ & Dispatcher, I think we will need to have both the lockWrite file by the writer, and the lockRead file by the reader. Otherwise, without the lockRead file the reader (Dispatcher) may slip under the gate before the lockWrite is imposed by the writer (DAQ). 2)The lockWrite imposed by the DAQ will have to wrap around the two-step process: i)tree is AutoSaved ii)gDirectory->SaveSelf(); My DAQ setup actually does not invoke TTree::AutoSave() directly, but rather makes use of the TTree::SetAutoSave method to tell the tree to automatically autosave after a certain number of bytes have been written (through basket dumps) to disk. Is it possible to include the SaveSelf step inside the TTree::AutoSave method? The lockWrite can then be built into the AutoSave method to wrap around both the writing of the new Tree header (and deleting of the old) and the writing of the directory keys which point to the new TTree. 3)I would like to have control over how long either the reader & writer waits for the other side to clear its lock. In particular on the writer (DAQ) side I have to be concerned about adding in any extra delays. One possibility for the DAQ that I would test is to have it not wait when a lockRead is encountered, but rather skip over that AutoSave, continue to Fill the TTree, and have it AutoSave at the next regularly scheduled interval. Missing an AutoSave now & then is probably something I can live with. A natural place to set the waittime for the writer is as an argument in the TTree::SetAutoSave method. 4)The lockRead imposed by the Dispatcher (reader) will have to wrap around the two-step process: gDirectory -> ReadKeys(); TTree* tree = (TTree*)gDirectory -> Get("MyTree"); I am not sure what overhead is involved if you should build the ReadKeys step into the TDirectory::Get method. Perhaps it could be a settable option of the TDirectory::Get method to force the reading in of new directory keys (upon user request) before attempting to retrieve the requested object. Again, thank you for taking the time to respond, and Anton I'm encouraged that you were able to get the lock file approach to work in your setup. Sue Kasahara
This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 11:50:35 MET