Re: [Gems-users] ordering in buffers

[Nauman Rafique <nrafique@xxxxxxxxxx>]

I think my problem is this statement inserted in Directory_Wakeup.C, a file
generated by SLICC.
-------------------------------------------------------------
    break;  // If we got this far, we have nothing left todo
-------------------------------------------------------------

This is being added towards the end in the while loop which is taking requests
out of the buffers. If my buffer has multiple requests, they would not be taken
out, causing a deadlock.
Should I take this break statement out or it is serving a purpose here. 
I do not want to mess up with/debug the coherence protocol again :)

Thanks.
-- 
Nauman


Quoting Mike Marty <mikem@xxxxxxxxxxx>:

> To add to this, if the RANDOMIZATION flag in ruby/config/tester.defaults
> is set to "true" (which is the default), then 100-cycle delays will be
> randomly added to messages in unordered buffers to encourage race
> conditions and protocol failures to occur for testing purposes.
> 
> --Mike
> 
> >
> > Nauman,
> >
> > It depends on the cache coherence protocol whether messages on certain
> > virtual channels can get out-of-order.  When a buffer is unordered, the
> > tester will allow messages to bypass eachother on a point-to-point link.
> > For instance, some protocols will deadlock if a GET request moves ahead of
> > a PUT request to the directory, which could happen if you set the requests
> > queue to be unordered.
> >
> > Look at the trace closer.  It is not always easy to tell what event causes
> > the deadlock, but through some persistence, you should find it.
> >
> > Brad
> >
> >
> >
> > On Wed, 30 Mar 2005, Nauman Rafique wrote:
> >
> > > I am wondering how much difference does it make if we set some of the
> buffers to
> > > be unordered?
> > > I have set a couple of buffers to be unordered, and Tester is reporting
> a
> > > deadlock. I am not really sure why deadlock occurs because from the
> trace,
> > > everything looks fine. And I am simulating with only 1 processor.
> > > If I set the buffer to be ordered, it works fine.
> > >
> > > Thanks.
> > > --
> > > Nauman
> > >
> > >
> > > _______________________________________________
> > > 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
> >
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
>