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

Reply via email to