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
