Re: [ROOT] TTree::AutoSave

From: Susan Kasahara (schubert@physics.umn.edu)
Date: Thu Oct 12 2000 - 17:55:38 MEST


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