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