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