[Gems-users] Managing Latencies

[Marco Solinas <marco.solinas@xxxxxxxxxxxx>]

Hello!

I was looking at the MOSI_SMP_directory_1level protocol. I don't 
understand what happens when the Directory receives a request for a 
given block while the Directory is still serving a previous request for 
the same block (for example, because the Directory has to read the block 
from the main memory, thus resulting in a huge latency), and the 
response msg hasn't been sent yet.
As an example of this situation, please consider the following example:
1. A cache (say Local) issues a GETX request to the Directory
2. The Directory receives the GETX, and has to load the block from MM 
(no sharers for the block are stored in the Directory)
3. Another cache (say Remote) issues a second GETS
4. The Directory receives the second GETS, while is still waiting for 
the block
Local   Home    Remote
|GETX   |       |
|  \    |       |
|    \  |       |GETS
|      \|      /|
|       L    /  |
|       A  /    |
|       T/      | <--- what happens here?
|       E       |
|       N       |
|       C       |
|       Y       |
|  Data/|       |
|    /  |       |
|  /    |       |
|/      |       |

In this context, the response msg hasn't been created yet when the 
second GETS arrives to the Directory. Is it possible, with SLICC, to 
manage such situation?
In the SLICC code of the Directory, I can read the following:

 action(b_dataToRequestor, "b", desc="Send data to requestor") {
   peek(requestNetwork_in, RequestMsg) {
     enqueue(responseNetwork_out, ResponseMsg, latency="MEMORY_LATENCY") {
        [...]
 }

Maybe my previous question can be reduced to: How does GEMS manage the 
<<latency="MEMORY_LATENCY">> constrain?
I hope that my question is clear (it is not a question on how the 
protocol behaves).
Thanks to all!
Marco