From: Kris Hagel (hagel@comp.tamu.edu)
Date: Thu Apr 03 2003 - 10:45:09 EST
Hiro, Part of my thinking was that this should make much better response when looking at histograms because the analysis thread would be using one processor and in principle one could expect the main thread to be executing on the other processor. I don't know my way around threads well enough to know if this is guaranteed to happen, but I would think the scheduler would be smart enough to do that. On the other hand, this is not VMS, so one never knows. Kris Hironori Ito wrote: > Hello. This sounds very very good. Does this mean that you do not > have to click pause when you want to see a histogram (Because it is so > slow, I usually do this although it is not necessary). Do two > different threads for ploting and filling data make better response??? > > Hiro > > Kris Hagel wrote: > >> Hello, >> In an attempt (shot in the dark) to alleviate the crashes of the >> SuperMon software when massive clicking is going on, I have changed >> the way the analysis manager loops over events. Previously the >> analysis manager looped over the events calling >> gSystem->ProcessEvents() after every event or buffer or some set of >> events (I forget exactly). Clicking on a spectrum to display it or >> double clicking to make a popup window or closing a canvas was >> executed inside these process events. Given that the crashes are >> somewhat random, my suspicion is that we get into a problem with >> timing between the x events and the rest of the program. The change >> made was to make the analysis loop a separate thread which only >> analyses the data. The main program will only deal with the button >> clicks and hopefully that will all happen independently of each >> other. The analysis loop thread does all of the writing (ie >> incrementing spectra) and the main thread only reads (ie displays >> histograms) The only place where there could be competition for >> writing data would be on clears while the analysis loop was in >> progress. This appears not to be an issue, but the possibility is >> non-zero that it could come back to bite. In that case locks would >> have to be implemented and I am not up to that right now. >> >> I implemented this and tested it reading real data files (run 8615) >> and it didn't crash when I made lots of popup windows. That means it >> is at least working to the level it did. The bad news is that it >> didn't crash very often for me anyway, so I have a hard time telling >> if I made an improvement. >> >> In the event (hopefully unlikely) that this makes things worse after >> it is installed in the operator account, I left a hook in to cause >> the behavior to be the same as the old. It is simply uncommenting >> the statement SetAnalysisLoopMode(kModeNormal) in the BrSuperMonitor >> constructor in case anyone is interested. I have not installed this >> in the operator account yet as I will wait for some coment. >> >> Regards >> >> Kris > > > >
This archive was generated by hypermail 2.1.5 : Thu Apr 03 2003 - 10:46:25 EST