> I was wondering why there are re- and descheduling methods. It seems to > me that they are a sort of error correcting mechanism for cases where > the occurrence of an event is not yet determined. However I can't think > of any reason why you would want to schedule an event if you're no > completely sure when or even if it will occur.
It happens all the time. Basically you plan for something to happen and then something else comes along and cancels that action. For example, in an out of order CPU, you'll speculatively issue an instruction and then another instruction comes back and tells you that your branch prediction was wrong, so you cancel that instruction. Or you've got a timer that is supposed to expire and cause an interrupt unless activity occurs, so you create the event, but the activity does occur and that causes the timer to reset. Just look through the code, there are several examples. Now, we do have two choices for canceling an event. Squashing and descheduling. Squashing marks an event as dead, but leaves it in the event queue. When the event is to be processed, the squashed flag is checked and the event is just skipped. That works for dynamically created events. For the timer expire type event, usually you'd statically allocate that kind of event and since you need to use the static event again, you need to deschedule and reschedule it. Nate _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
