I'm fine with #1 or #3... since you have to subclass Event to override process() anyway, just moving the queue pointer to the subclass for those that need it doesn't seem so bad to me. #2 and #4 seem unnecessarily complex and/or pervasive.
Steve On Sun, Jun 29, 2008 at 3:34 PM, Ali Saidi <[EMAIL PROTECTED]> wrote: > 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 > _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
