Re: [Gems-users] Another question on MOESI protocol

["Cong Wang" <jameswang99@xxxxxxxxx>]

Hi Xuehai:
    It seems to me that you do not want to retain the data after you
write it and some other processor requests it because it could be a
shared resource, such as a lock. And you really want to optimize for
the requester to have full writable right so that it could immediately
update the lock. But you are correct in the sense that, it doesn't
have to do this. It could just downgrade to S state instead of
invalidating. But it is just one particular implementation and you are
welcome to modify it to suit your purpose.
Regards
James Wang

On Sun, Nov 23, 2008 at 12:33 AM, Xuehai Qian <xuehaiq@xxxxxxxxx> wrote:
> Hi Everyone,
>    I have another question about the one of the cache protocols in
> GEMS(MOESI_directory).
>    Suppose the block in a cache (P1) is in MM state, and another cache(P2)
> issues a load, the result according to the protocol is P1 sends the data to
> P2, and the data is exclusive dirty, after that, P1 invalidate itself, and
> P2 has the data, and the data is in state M. Here, it is the only senario
> that the state can change to M, but why we cannot let P1 still keeps the
> data, and the after this transaction, the states in both of the caches are
> shared (P1 is O_D, P2 is S)?? Following the original protocol, if P1 later
> load the block, it will encounter a miss, and will have longer latency. The
> protocol invalidate a locally stored copy in any situation (GETX or GETS),
> the motivation or benefit of doing that is not clear to me. But if a
> modified block has migrated to another cache (for example in M or O_D)
> state, the owner cache will keep the block as long as no remote caches'
> store. Why the MM cannot be handle in this way as well? But in that case,
> there is no transition being able to move state machine to "M".
>
>    I guess there is a coner case preventing what I said above, it is good if
> you can tell me the corner case, and I will understand it.
>   Thanks!
>
> Xuehai
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> Use Google to search the GEMS Users mailing list by adding
> "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
>
>
>



-- 
Regards
James Wang