diff options
author | Andreas Sandberg <andreas.sandberg@arm.com> | 2015-07-07 09:51:05 +0100 |
---|---|---|
committer | Andreas Sandberg <andreas.sandberg@arm.com> | 2015-07-07 09:51:05 +0100 |
commit | f16c0a4a90ad1050cf7d1140916c35d07b1cb28e (patch) | |
tree | 2ba143ee880e5daaa567e83e402454518ba5f16d /src/mem/ruby/structures/PersistentTable.hh | |
parent | d5f5fbb855e8de8c64444dd02f0ed7c27866578c (diff) | |
download | gem5-f16c0a4a90ad1050cf7d1140916c35d07b1cb28e.tar.xz |
sim: Decouple draining from the SimObject hierarchy
Draining is currently done by traversing the SimObject graph and
calling drain()/drainResume() on the SimObjects. This is not ideal
when non-SimObjects (e.g., ports) need draining since this means that
SimObjects owning those objects need to be aware of this.
This changeset moves the responsibility for finding objects that need
draining from SimObjects and the Python-side of the simulator to the
DrainManager. The DrainManager now maintains a set of all objects that
need draining. To reduce the overhead in classes owning non-SimObjects
that need draining, objects inheriting from Drainable now
automatically register with the DrainManager. If such an object is
destroyed, it is automatically unregistered. This means that drain()
and drainResume() should never be called directly on a Drainable
object.
While implementing the new functionality, the DrainManager has now
been made thread safe. In practice, this means that it takes a lock
whenever it manipulates the set of Drainable objects since SimObjects
in different threads may create Drainable objects
dynamically. Similarly, the drain counter is now an atomic_uint, which
ensures that it is manipulated correctly when objects signal that they
are done draining.
A nice side effect of these changes is that it makes the drain state
changes stricter, which the simulation scripts can exploit to avoid
redundant drains.
Diffstat (limited to 'src/mem/ruby/structures/PersistentTable.hh')
0 files changed, 0 insertions, 0 deletions