----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1664/#review3897 -----------------------------------------------------------
I think the need for this somewhat depends on the threading model. It seems possible to have a "global" curTick per thread using tls and i'd imagine that at a checkpoint all threads should reach a quantum barrier before a checkpoint is allowed to be generated. Furthermore, I think it requires changes to the checkpoint upgraded, since the curTick value would move. Out of curiosity, is this just a small piece of a large amount of code you've written for multithreading or is this just a single isolated change? Since I imagine there might be a few false starts while going down the threading path, we might want to wait until there some number of changes accumulate before committing small changes that might not stick around. - Ali Saidi On Jan. 24, 2013, 12:22 p.m., Nilay Vaish wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1664/ > ----------------------------------------------------------- > > (Updated Jan. 24, 2013, 12:22 p.m.) > > > Review request for Default. > > > Description > ------- > > Changeset 9480:c1585edc3d31 > --------------------------- > checkpoint: move curTick from globals to eventq > curTick is no longer a global variable. In future, we would likely move > towards > parallel simulation with multiple event queues. Hence, the curTick should be > moved to the section on the event queue. > > > Diffs > ----- > > src/sim/eventq.cc f9e76b1eb79a > src/sim/serialize.cc f9e76b1eb79a > > Diff: http://reviews.gem5.org/r/1664/diff/ > > > Testing > ------- > > > Thanks, > > Nilay Vaish > > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev