I vote for (1) until it can be shown that it matters. A single pointer doesn't seem like a big deal, especially since most of the things we create and destroy frequently aren't SimObjects but other classes.
Ali On Jun 29, 2008, at 12:23 PM, nathan binkert wrote: > I'm nearly done with the first step of getting parallel M5 working. > -- Add an EventQueue pointer to every SimObject and add > schedule()/deschedule()/reschedule() functions to the Base SimObject > to use that event queue pointer. > -- Change all calls to event scheduling to use that EventQueue > pointer. > -- Remove the schedule/deschedule/reschedule functions on the Event > object. Now, you must create an event and schedule it on an event > queue. > > An example of this is something like this: > > old: > new LinkDelayEvent(this, packet, curTick + linkDelay); > > new: > Event *event = new LinkDelayEvent(this, packet); > this->schedule(event, curTick + linkDelay); > > I'd like to remove the queue pointer from the event object since there > is only one use case where you've scheduled an event and you don't > know which queue it's on if you want to de/reschedule it. It's for > repeat events like the SimLoopExitEvent. > > Here are the options: > 1) Leave the queue pointer in the object > 2) Pass the queue pointer as a parameter to the process() function > 3) Record the queue pointer in just those objects that require it > 4) Create a new flag to the event called AutoRepeat, create a virtual > function that can be called to determine the repeat interval, and add > support for repeat in the event queue > 5) Create a thread local global variable called currentEventQueue. > (I hate this idea) > > I go back and forth as to the right thing to do. I'd really like to > avoid the queue pointer in all objects so we can keep events small, > but I guess it can easily be argued that I shouldn't keep that > optimization unless I know that it will pay off, but the only way to > know if it will pay off is to just do it. I also basically hate #5 > and it's on the bottom of my list. One issue is that because of the > committed instruction queue, there can be more than one event queue in > a given thread. > > Anyone have any opinions? > > BTW: I'll write up a Parallelizing M5 wiki page in the next day or so > that enumerates all of my plans. > > Nate > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev