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