Re: [Gems-users] confused by a comment in the MOESI LogTM code

[郭锐 <timmyguo@xxxxxxxxxxxxxxxx>]

Well, I tried it out by experiment. What a terrible livelock.......

> -----Original Message-----
> From: gems-users-bounces@xxxxxxxxxxx
[mailto:gems-users-bounces@xxxxxxxxxxx]
> On Behalf Of 郭锐
> Sent: Wednesday, January 24, 2007 12:54 AM
> To: gems-users@xxxxxxxxxxx
> Subject: [Gems-users] confused by a comment in the MOESI LogTM code
> 
> I find the following comment in the MOESI_SMP_LogTM_directory-cache.sm:
>   transition(MM, {Fwd_GETS_P, Fwd_GETX_P}) {
>     // Buffer requests instead of nacking.
>     // There could be race between
>     // the retry and restarting
>     // the transaction, which can
>     // cause livelock.
>     // Would be nice to have an extra state
>     // here. When the abort finishes, the
>     // block will be in M, but
>     // transactionally clean.  Ideally, we'd
>     // only buffer the one request that
>     // caused the abort and nack the rest.
>     // Not sure how to do that here.
>     zz_recycleForwardRequestQueue;
>   }
> 
> Firstly, I understand this protocol quite well, and have modified this
> protocol to fit my need. But I fail to imagine such a livelock referred by
> this comment when using nacking here. Could anybody give me an example?
> Thanks in advance!
> 
> G.R.
> 
> _______________________________________________
> 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.