summaryrefslogtreecommitdiff
path: root/src/mem/tport.hh
diff options
context:
space:
mode:
authorNathan Binkert <nate@binkert.org>2008-10-09 04:58:23 -0700
committerNathan Binkert <nate@binkert.org>2008-10-09 04:58:23 -0700
commit8291d9db0a0bdeecb2a13f28962893ed3659230e (patch)
treeccd4df59a41cd3d8e4ac35adc591315f44425479 /src/mem/tport.hh
parent68c75c589b2e006292f623bd6428754d7d590f01 (diff)
downloadgem5-8291d9db0a0bdeecb2a13f28962893ed3659230e.tar.xz
eventq: Major API change for the Event and EventQueue structures.
Since the early days of M5, an event needed to know which event queue it was on, and that data was required at the time of construction of the event object. In the future parallelized M5, this sort of requirement does not work well since the proper event queue will not always be known at the time of construction of an event. Now, events are created, and the EventQueue itself has the schedule function, e.g. eventq->schedule(event, when). To simplify the syntax, I created a class called EventManager which holds a pointer to an EventQueue and provides the schedule interface that is a proxy for the EventQueue. The intent is that objects that frequently schedule events can be derived from EventManager and then they have the schedule interface. SimObject and Port are examples of objects that will become EventManagers. The end result is that any SimObject can just call schedule(event, when) and it will just call that SimObject's eventq->schedule function. Of course, some objects may have more than one EventQueue, so this interface might not be perfect for those, but they should be relatively few.
Diffstat (limited to 'src/mem/tport.hh')
0 files changed, 0 insertions, 0 deletions