[Gems-users] about transition behaviors

["Jiho \"Ray\" Choi" <jray319@xxxxxxxxx>]

Hello,

I am new to GEMS, and I got some questions while writing a new protocol.

I looked at sample protocols and found out that there are mainly five different behaviors of transitions.

1. First, there is a transition which invokes a set of actions and dequeues the message which may trigger the event. I think it is a typical case.

2. There is a transition which only dequeues the message. It means that the message can be safely ignored at the state.

3. There is a transition which recycles the message. I think it is when it's waiting for a certain event at the transient state. In other words, the message should not be ignored but it should be handled at the other state, and it is okay to serve other messages first.

4. There is a transition which does not dequeue or recycle. While recycling allows other messages served first, in this case, it stalls till the state is changed so that the message can be served.

For example, when L2 receives a GET message and the requested block is not present and the L2 cache is full, it triggers an event to replace one of existing blocks. In this case, the transition triggered by the event will not dequeue or recycle the GET message. Then, it stalls until it receives the data from the memory, changes its state to SHARED, and serves the GET message sitting at the head of the queue.

5. Lastly, for some events, a transition is not specified. It's because the writer is sure that those events are never triggered at some states. However, in this case, I think it's safer to dequeue the triggering message.

Is my understanding correct? Am I missing any?

I am really not sure about the difference between the third and the fourth.

Regarding the fourth behavior, how does it wake up in_port when it is ready to serve the message? Does in_port periodically wake up if not empty? If not, even if the GET message is luckily served thanks to subsequent incoming messages, since (# of wake up) should be same to (# of dequeue) without periodic wakeup, the last few messages will remain unserved. So, I guess in_port wakes up not only by newly arriving messages but also by some timer. Is it right?

Thank you for your supports.

Best regards,

Ray