Hello, This is a great question!
The short answer is I believe that the coherence protocol is correct. (Though, there could always be unexpected bugs.) The slightly longer answer: You are probably seeing that the store happens before the load in "real" time. However, in the processors' view (i.e., *logical* time), the load is actually happening before the store. As long as the processors are correctly implementing their consistency models (e.g., if they are sequentially consistent then they don't allow any reorderings between load and store instructions within each thread), then as long as it *appears* that the load completed before the store, then it's a correct implementation. To put it another way, if the thread doing the load cannot tell that the load happened after the store (in real time) then it is safe. It's something like the Lamport Clock: https://en.wikipedia.org/wiki/Lamport_timestamp We have a saying in English: "If a tree falls in a forest and no one is there to hear it, does it make a sound?" Similarly, if a thread does a store to an address, but no other thread can tell what the ordering needs to be, it's OK to reorder it :). Cheers, Jason On Tue, Mar 21, 2023 at 11:50 PM 章志元 via gem5-users <gem5-users@gem5.org> wrote: > Hi all, > I've been looking into the default MOESI CMP Directory Protocol, and it > came to my attention that, regarding SM states in L1 Cache (Transient state > during a Shared to Exclusive Upgrade due to a store miss), when a load > arrives from the local core (which hits since the Cache is technically > still in Shared state), the cache will return the old Shared Datablk as its > load hit result. Will it cause incoherence issues in memory ordering > between the core and the memory system, since the CPU commits the store > first and then commit the load returning the old data, but the memory > system sees the load hit finish first, and then see the GETX finish? > Also I already speculate that such loads will probably not arrive at the > L1 Cache controller, since it would be blocked or forwarded with newer data > due to outstanding stores in the lsq or the mandatory queue. I'm just > wondering if the cache protocol itself is solid in terms of request > ordering. > Thanks in advance! > Zhang Zhiyuan > 2023.3.22 > -- > 姓名：章志元 > 手机：17717877306 > 邮箱：zhiyuanzhan...@fudan.edu.cn > > > _______________________________________________ > gem5-users mailing list -- gem5-users@gem5.org > To unsubscribe send an email to gem5-users-le...@gem5.org >
_______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
