Hi Rene, good to know that! I admit that we did not trace this change because we solved the problem anyway. Can make it for Stefano easier. Still he must be aware of the thread problematic. Hans 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