Re: [Gems-users] TBE allocation


Date: Tue, 20 Sep 2005 11:26:33 -0500 (CDT)
From: Mike Marty <mikem@xxxxxxxxxxx>
Subject: Re: [Gems-users] TBE allocation
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
>
[← Prev in Thread] Current Thread [Next in Thread→]