-----------------------------------------------------------
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

Reply via email to