gvoskuilen

@mrutt92 memHierarchy implements the atomicity logic for ReadLock/WriteUnlock in the L1 caches only. If you wanted to add in that functionality, look at memHierarchy/memBackend/memBackendConvertor.cc::handleMemEvent() and the function it calls, memHierarchy/memBackend/membackendConvertor.h::setupMemReq()....

I made assignments so we can track this. If you can mock something up and identify what needs to changed/added, that'd be great.

The lifetime can be tied to the CustomRequest/Response unless the CustomData object is explicitly transferred. As is, request/response don't have a way to easily specify that the CustomData ownership has...

Which version of SST are you using? In the devel branch for example, `isStoreConditional` returns true if the request is a `GetX` or `Write` and the `F_LLSC` flag is set....

The changes are in v13.0.0_Final (memEvent.h implementation of `isStoreConditional`). Correct on the logic I described being `StandardMem::LoadLink` and `StandardMem::StoreConditional` only. `ReadLock` and `WriteUnlock` define a non-conditional atomic are implemented differently.

Update: about ready to publish. Developing test for docker file. Also resolving issues with ARM-based mac & docker.

@samkitjain The scratchpads don't have that capability and are not part of the global memH address space. We are working on adding that capability. I'll leave this issue open and...

Does this compile with the current sst-elements/devel branch and pass the tests in that repo? If not, it will fail testing.

I agree with the idea, it would be better to have the CustomRequest/Response explicitly take and hand off ownership including responsibility for delete. And if memH or any other elements...

Thanks. We'll get this in once we figure out how to phase it in without breaking things. Feel free to propose a way to do that if you think of...