On Wed, Nov 11, 2009 at 9:22 PM, nathan binkert <[email protected]> wrote: >> On the face of it, it doesn't sound that bad, but how often does this >> really occur? If you have a SimObject that regularly has multiple >> events scheduled at the same tick & priority, and is smart enough to >> keep track of when that happens, why not have that SimObject chain its >> own events itself (i.e., it just schedules one event on the event >> queue but that event has the capability of having additional events >> tacked on to it). > > That's what I've been doing and it's annoying. It's a lot more work. > There's just more code that must be written. I wrote a class that did > exactly that for me and then I thought, why bother?
How is it a lot more work? I would think that the hard part is tracking the previously scheduled events so that you know when you have two at the same tick. Having a base ChainableEvent class that has a next pointer in it and a method to process the events linked off of that doesn't sound so bad. Plus it sounds like you already have that code written :-). > It's also lower > performance because you'll have two virtual function calls (unless the > second is not virtual). Depends on how you structure the processing of the chained events, I guess. I don't have a clear enough picture of what you're doing to follow. Plus you would save a few instructions by not having to compare each timestamp against curTick as you walk the list... I don't have a really strong feeling either way, but my gut reaction is that it's a very specific and perhaps uncommon situation, and I'm reluctant to extend a very universal and generic interface to optimize for it unless there's really no comparable way to handle this special case outside of the core event queue. Steve _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
