On Fri, Jun 24, 2011 at 4:01 PM, <[email protected]> wrote: > Hi, > > I like Steve's idea. The basic idea is similar to the current > implementation (i.e., having a second event queue) but without hijacking > Ruby APIs. > > I have a question regarding Nate's and Steve's discussion on the head > pointer. Do I need to have a swap function implemented or I can make the > pointer public and change it (e.g., set it NULL)? >
We definitely don't want to just make the pointer public... something like a swap method is much preferred. Steve > > Thanks, > Somayeh > > > On Fri, Jun 24, 2011 at 11:52 AM, nathan binkert <[email protected]> > wrote: > > > >> > Your latest suggestion is very similar to how the current patch works. > >> The only difference is that the Ruby event queue shim layer does a > >> logical > >> pointer swap and not a physical pointer swap within the main gem5 event > >> queue itself. I'm somewhat leery of making the event queue head pointer > >> public, but if you're ok with it, then I'll go along with it. It > >> certainly > >> will be less work for Somayeh...no need to worry about events scheduling > >> past T-1 ticks, etc. > >> > >> Let's definitely not make the head pointer public. I think that the > >> right thing to do is create a swap() function (for those of you that > >> don't know, swap is a very common concept in the STL). Then we can > >> create a temporary queue, swap it with the main queue, run everything, > >> and when it is done, swap it back. The swap function would be public, > >> but nothing else would be. > >> > > > > Agreed, I was about to say something similar but you beat me to it. This > > could also be done by making the copy and assignment operators public > > (swap > > the state out by copying it to a new object, restore by assigning the > > state > > back). > > > > Of course, we really just want to swap the head pointer and not > > necessarily > > the name, so maybe a swap() on the head pointer would be better, but I > > don't > > know that it's worth quibbling about whether that happens or not. > > > > > >> This seems to me to be the safest way to ensure that everything works > >> as expected. I'd also like to see _curTick moved into the eventQueue > >> itself, and the global curTick() function should call > >> mainEventQueue.curTick(). (Is this what you've done for your multiple > >> event queue patch steve?) > >> > > > > No, my patch just puts _curTick in TLS using __thread. It's been a > while, > > but I'm pretty sure there are places where curTick() gets called where > you > > don't have easy access to which queue you're on (e.g., inside of a > DPRINTF > > that's not in a method associated with an EventManager object) so you > > really > > want a TLS pointer to tell you where you're at. You could put curTick in > > the event queue and then have an EventQueue* in TLS, but that seems like > > an > > unnecessary indirection, unless it turns out that we need that queue > > pointer > > to be in TLS also (which may happen, but I'm not convinced that it will). > > > > It's an interesting debate to have, but I'd prefer to see it decoupled > > from > > Ruby warm-up so that Somayeh doesn't get held up on it. > > > > Steve > > _______________________________________________ > > gem5-dev mailing list > > [email protected] > > http://m5sim.org/mailman/listinfo/gem5-dev > > > > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
