From ac1368df50af123b32b41d7115ea4a0f15f7c97f Mon Sep 17 00:00:00 2001 From: Andreas Hansson Date: Fri, 6 Nov 2015 03:26:21 -0500 Subject: mem: Unify delayed packet deletion This patch unifies how we deal with delayed packet deletion, where the receiving slave is responsible for deleting the packet, but the sending agent (e.g. a cache) is still relying on the pointer until the call to sendTimingReq completes. Previously we used a mix of a deletion vector and a construct using unique_ptr. With this patch we ensure all slaves use the latter approach. --- src/mem/tport.cc | 12 ++---------- 1 file changed, 2 insertions(+), 10 deletions(-) (limited to 'src/mem/tport.cc') diff --git a/src/mem/tport.cc b/src/mem/tport.cc index aa783ada0..9f9403a22 100644 --- a/src/mem/tport.cc +++ b/src/mem/tport.cc @@ -62,12 +62,6 @@ SimpleTimingPort::recvFunctional(PacketPtr pkt) bool SimpleTimingPort::recvTimingReq(PacketPtr pkt) { - /// @todo temporary hack to deal with memory corruption issue until - /// 4-phase transactions are complete. Remove me later - for (int x = 0; x < pendingDelete.size(); x++) - delete pendingDelete[x]; - pendingDelete.clear(); - // the SimpleTimingPort should not be used anywhere where there is // a need to deal with inhibited packets if (pkt->memInhibitAsserted()) @@ -82,10 +76,8 @@ SimpleTimingPort::recvTimingReq(PacketPtr pkt) assert(pkt->isResponse()); schedTimingResp(pkt, curTick() + latency); } else { - /// @todo nominally we should just delete the packet here. - /// Until 4-phase stuff we can't because the sending - /// cache is still relying on it - pendingDelete.push_back(pkt); + // queue the packet for deletion + pendingDelete.reset(pkt); } return true; -- cgit v1.2.3