Hi Hans, I agree with your remarks that a socket communication is a better solution than pure shared memory. You make a remark that Streaming with Root is not thread safe. I believe that this statement is not true anymore. We introduced in version 3.03 a change in TBuffer such that TBuffer knows its parent and does not rely anymore on the global gFile. Rene Brun Essel Dr.Hans-Georg wrote: > > Hi Stefano, > I just read your dialog about TMapFile. We had the same situation, i.e. > having a histogram producer (analysis), and a histogram consumer (display) > running in separate tasks. The problem with the TMapFile is: > The consumer must update a changed object, and the producer must get a copy. > How to make sure that the consumer gets always an up to date copy? > 1. The producer updates each time an objects changes. This kills you if > this is an analysis filling 50 MB of histograms per event. > When the consumer is satisfied to get not the last status, but say some > minutes ago, > the producer could update every minute to reduce the copy operations. > 2. The consumer, before getting the object, informs the producer to update > this object. > This means to establish a communication between both. Even in this case > the object has to be copied two times whenever the consumer wants to get it. > > Once you have a communication established via sockets, it is much easier > to send the histogram on request through the socket. Thus you dont need > TMapFile at all and > copy the histogram only if consumer requests it. With the streaming > mechanisms > sending objects through sockets is pretty easy. The performance is close to > memory copy (both tasks on same machine). > However, you have to solve the problem that the producer always must respond > to the request. Either th producer is looping all the time and can scan the > socket > for requests, or it must run a thread listening for requests. In this case > you must take care of the problems with threads in ROOT, because streaming > objects is not thread save, i.e. you must lock the streaming against the > main thread. > > These considerations lead us to the mechanisms implemented in Go4. > The Go4 Thread manager and Task handler solves exactly this problem. > You find articles about these on http://go4.gsi.de > > Maybe these remarks are some help > Hans > > Dear Rene, > we have of course read carefully the documentation you suggest and > exactly followed the prescriptions. Nevertheless we still have problems: > when the consumer process remaps ( as read-only ) the TMapRegion created > by the producer, we notice that the single histo we store is shown to be > present in the Map File ( calling TMapFile Print() method ) but any call > to a method of the histo crash the program. > > a snapshot from producer Print > > Memory mapped file: daq.map > Title: DAQ Monitor Histograms > Option: CREATE > Mapped Memory region: 0x67747000 - 0x6774f000 (0.03 MB) > Current breakval: 0x6774f000 > > a snapshot from consumer Print > > Memory mapped file: daq.map > Title: DAQ Monitor Histograms > Option: READ > Mapped Memory region: 0x67747000 - 0x677c1000 (0.48 MB) > Current breakval: 0x677c1000 > Object Class Size > cardDistribution TH1F 1024 > > *** Break *** segmentation violation > > Thanks for any further suggestion. > > Stefano & Dario > > > Hi Stefano & Dario, > > > > Did you follow carefully the instructions given at: > > http://root.cern.ch/root/htmldoc/TMapFile.html#TMapFile:SetMapAddress > > > > for SetMapAddress and MaptoAddress ? > > > > Rene Brun > > > > -- > ********************************************** > Dr. Stefano Magni > I.N.F.N Via Celoria 16, Milano > tel : 0250317738 > **********************************************
This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:50:51 MET