Re: [Gems-users] Question about MOSI_SMP_directory_1level

["Mike Marty" <mikem@xxxxxxxxxxx>]

Yeah, I think that's right.  

MOESI_SMP_directory doesn't rely on point-to-point ordering and thus handles
this race differently.

--Mike

> -----Original Message-----
> From: gems-users-bounces@xxxxxxxxxxx [mailto:gems-users-
> bounces@xxxxxxxxxxx] On Behalf Of Greg Byrd
> Sent: Tuesday, September 05, 2006 7:02 PM
> To: Gems Users
> Subject: Re: [Gems-users] Question about MOSI_SMP_directory_1level
> 
> I don't think this can happen because: (1) forwarded GETS and PUTX ack
> are sent on the same network (forwardedRequestNetwork), and (2) the
> network enforces point-to-point ordering.  Therefore, the cache will
> always receive the GETS first.
> 
> ...Greg
> 
> 
> Sean Ryan Leventhal wrote:
> >    I have been modifying this protocol and have noticed a rare race
> > condition which I do not think it handles.  In particular it happens
> like
> > this:
> >
> > 1) Owner issues PUTX due to a cache replacement
> > 2) Before this arrives at the directory a gets (or getx) is forwarded to
> > the owner by the directory
> > 3) The directory then responds to the PUTX
> > 4) The response to the PUTX arrives at the owner first, transitioning
> the
> > state to Invalid
> > 5) The forwarded GETS arrives.
> >
> > Is this handled somewhere I am not seeing, or is this a genuine issue
> with
> > this protocol?
> >
> > Sean
> > _______________________________________________
> > 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.
> >
> >
> 
> _______________________________________________
> 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.