Just to summarize this whole thread. TMapFile and shared memory in conjunction with C++ is far from ideal due to the fact that objects (of classes with virtual functions) allocated in shared memory in one process are not directly usable in another process. This is due to the fact that the vtpr is invalid in the consumer process. One would either have to patch the vptr in the consumer (compiler dependent) or one has to serialize and de-serialize the object into and from shared memory. The latter option is used in TMapFile. In addition there is the problem with the varying location of the shared memory segment due to the many shared libraries (plugins) that can be loaded at run time. All in all a better method as described by Hans Essel is to use directly sockets to communicate objects (almost the same overhead as for shared memory, serialize and de-serialize). An good starting example of such an approach can be found in $ROOTSYS/tutorials/spyserv.C and spy.C. Cheers, Fons. On Fri, 2002-04-26 at 11:20, Rene Brun wrote: > 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 > > ********************************************** -- Org: CERN, European Laboratory for Particle Physics. Mail: 1211 Geneve 23, Switzerland E-Mail: Fons.Rademakers@cern.ch Phone: +41 22 7679248 WWW: http://root.cern.ch/~rdm/ Fax: +41 22 7679480
This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:50:51 MET