Also if you want to prevent this, you can simply bounce the data/tokens to
memory when a processor receives them without a TBE allocated. Just add
this transition and remove the ones in my previous message:
transition({NP, O, S, I}, {Ack, Data_Shared, Data_Owner,
Data_Owner_All_Tokens}) {
b_bounceResponse;
n_popResponseQueue;
}
--Mike
> It is possible. MOESI_SMP_token-cache.sm includes the following
> transitions that give a processor modify permission when a TBE is not
> allocated:
>
> transition(O, Data_Shared_All_Tokens, M) {
> w_assertIncomingDataAndCacheDataMatch;
> q_updateTokensFromResponse;
> n_popResponseQueue;
> }
>
> transition(O, Ack_All_Tokens, M) {
> q_updateTokensFromResponse;
> n_popResponseQueue;
> }
>
> transition(S, Data_Owner_All_Tokens, M) {
> w_assertIncomingDataAndCacheDataMatch;
> q_updateTokensFromResponse;
> n_popResponseQueue;
> }
>
> transition(I, Data_Owner_All_Tokens, M) {
> u_writeDataToCache;
> q_updateTokensFromResponse;
> n_popResponseQueue;
> }
>
>
> However these transitions should be quite rare in practice and only occur
> under severe network delays/reorderings. For example, consider this
> weird situation:
>
> P1 broadcasts GETX. Message to P5 is severely delayed
> P5 broadcasts GETX
> P3 responds to P1's request, P1 gets all tokens
> P1 receives P5's request and responds to P5
> P5 finally receives delayed request from P1 and responds to P1
> P1 receives data and all tokens, and has an Invalid tag allocated, so it
> keeps them and now has exclusive permission. no TBE was present.
>
> --Mike
>
>
> > I am currently modifying MOESI_SMP_token, and I was wondering if there are
> > any situations in which the cache can receive modify permission without
> > having a TBE allocated. It seems like it cannot happen at first glance,
> > but I have an error which as far as I can tell would be caused by
> > something like this.
> > _______________________________________________
> > Gems-users mailing list
> > Gems-users@xxxxxxxxxxx
> > https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> >
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
>
|