On Mon, Aug 20, 2012 at 6:27 PM, Jan Hubicka <hubi...@ucw.cz> wrote: >> Xinliang David Li <davi...@google.com> writes: >> > >> > Process level synchronization problems can happen when two processes >> > (running the instrumented binary) exit at the same time. The >> > updated/merged counters from one process may be overwritten by another >> > process -- this is true for both counter data and summary data. >> > Solution 3) does not introduce any new problems. >> >> You could just use lockf() ? > > The issue here is holding lock for all the files (that can be many) versus > number of locks limits & possibilities for deadlocking (mind that updating > may happen in different orders on the same files for different programs built > from same objects) > > For David: there is no thread safety code in mainline for the counters. > Long time ago Zdenek implmented poor-mans TLS for counters (before TLS was > invented) > http://gcc.gnu.org/ml/gcc-patches/2001-11/msg01546.html but it was voted down > as too memory expensive per thread. We could optionaly do atomic updates like > ICC > or combination of both as discussed in the thread. > So far no one implemented it since the coverage fixups seems to work well > enough in > pracitce for multithreaded programs where reproducibility do not seem to be > _that_ > important. > > For GCC profiled bootstrap however I would like to see the output binary to be > reproducible. We realy ought to update profiles safe for multple processes. > Trashing whole process run is worse than doing race in increment. There is > good > chance that one of runs is more important than others and it will get trashed. > > I do not think we do have serious update problems in the summaries at the > moment. > We lock individual files as we update them. The summary is simple enough to > be safe. > sum_all is summed, max_all is maximum over the individual runs. Even when you > combine > mutiple programs the summary will end up same. Everything except for max_all > is ignored > anyway. > > Solution 2 (i.e. histogram streaming) will also have the property that it is > safe > WRT multiple programs, just like sum_all.
I think the sum_all based scaling of the working set entries also has this property. What is your opinion on saving the histogram in the summary and merging histograms together as best as possible compared to the alternative of saving the working set information as now and scaling it up by the ratio between the new and old sum_all when merging? Thanks, Teresa > > Honza >> >> -Andi -- Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413
