一文看懂CHI总线的transaction order

1. multi-copy atomicity

CHI协议中使用的内存模型要求是multi-copy atomicity，即多副本原子性。所有兼容组件必须确保所有写请求都是多副本原子性的。

如果满足以下两个条件，则将写操作定义为多副本原子操作：

1. 对同一地址的所有写操作都是序列化的，也就是说，所有请求者以相同的顺序观察到它们，尽管有些请求者可能不会观察到所有的写操作。

2. 对一个地址的读操作不会返回写操作的值，直到所有的请求者都观察到这个写操作。

在CHI协议中，如果两个地址的cacheline地址和物理地址空间（PAS）属性相同，则它们在一致性、observe和hazard方面被认为是相同的。

2. transaction order

除了使用Comp响应来排序来自请求者的请求顺序外，CHI协议还定义了在RN节点和HN节点之间、HN节点和SN节点之间的请求保序机制。

请求中的Order字段用来支持保序。Order字段表明事务需要以下保序之一：

Request Order：保证从同一agent到同一地址的多个事务的顺序。

Endpoint Order：保证从同一agent到同一endpoint地址范围的多个事务的顺序。

Ordered Write Observation（OWO）：保证系统中其他agent对来自单个agent的一系列写事务的观察顺序。

Request Accepted：保证完成者只有在接受读请求时才会发送一个肯定的确认。

对于以下事务，Order字段必须设置为非零值：

ReadNoSnpReadNoSnpSepReadOnce*WriteNoSnpWriteNoSnpDefWriteNoSnp*CMOWriteNoSnpZeroWriteUniqueWriteUnique*CMOWriteUniqueZeroAtomic

当ReadNoSnp或ReadOnce*事务需要Request Order或Endpoint Order时：

• 请求者需要一个ReadReceipt来确定何时可以发送下一个保序的请求。在完成者处，ReadReceipt意味着请求已到达下一个保序点，该点将保持请求收到的顺序：
  • 对于Request Order的请求，它将保持从相同来源到相同地址的请求之间的顺序。
  • 对于Endpoint Order的请求，它将保持从相同来源到相同endpoint地址范围的请求之间的顺序。

能够发送单独的Non-data和Data-only响应的Completer可以发送RespSepData响应而不是ReadReceipt，并实现相同的功能行为。

当WriteNoSnp、WriteSnpDef、WriteNoSnpZero或Non-snoopable Atomic事务需要Request Order或Endpoint Order时：

请求者需要DBIDResp或DBIDRespOrd来确定何时可以发送下一个保序的请求。完成者发送一个DBIDResp或DBIDRespOrd响应意味着一个数据缓冲区是可用的，并且写请求已经达到了PoS，它将保持请求在他们收到的顺序：
• 对于Request Order的请求，它将保持请求之间的顺序从相同的来源到相同的地址。对于Endpoint Order的请求，它将在来自相同来源到相同endpoint地址范围的请求之间保持顺序。

当没有ExpCompAck断言的WriteUnique事务，或WriteUniqueZero或Snoopable Atomic事务需要请求顺序时：

请求者需要DBIDResp或DBIDRespOrd来确定何时可以发送下一个有序的请求。完成者发送一个DBIDResp或DBIDRespOrd响应意味着它将维持来自同一来源的相同地址的请求之间的顺序。

当WriteUnique或WriteNoSnp事务需要OWO时：

CompAck是必需的。请求节点必须断言ExpCompAck。请求节点需要一个DBIDResp或DBIDRespOrd。completer是PoS， PoS发送DBIDResp或DBIDRespOrd意味着：
• 数据缓冲区可用。PoS保证这次写操作的一致性操作的完成不依赖于后续需要有序写观察的写操作的一致性操作的完成。在收到CompAck之前，写操作不可见。

当ReadNoSnp或ReadNoSnpSep将Order字段设置为0b01时，来自Completer的ReadReceipt响应保证Completer已经接受请求，并且不会发送RetryAck响应。

RN向HN发送ReadNoSnp-1请求。HN接受请求并向RN返回ReadReceipt-1响应。收到ReadReceipt-1响应后，RN向HN发送ReadNoSnp-2请求。HN不能立即接受ReadNoSnp-2请求，并向RN返回RetryAck-2响应。在重发ReadNoSnp-2请求之前，RN必须等待从HN发送PCrdGrant。此时，RN不发送ReadNoSnp-3，因为它希望在ReadNoSnp-2之后发送ReadNoSnp-3。这个顺序要求在ReadNoSnp-3发送到HN之前，必须先在HN接受ReadNoSnp-2。在收到适当的PCrdGrant后，RN重新发送ReadNoSnp-2请求。HN接受请求并向RN返回一个ReadReceipt-2响应。RN收到ReadReceipt-2响应后，向HN发送ReadNoSnp-3请求。HN接受请求并向RN返回ReadReceipt-3响应。

10. 每个读事务都在请求者接收到Comp和数据时完成。图2-34没有显示。

2.1 Streaming Ordered Write

Streaming Ordered Write的架构机制，只适用于WriteUnique和WriteNoSnp事务。

如果请求者希望观察到一系列写操作按照其发出的顺序执行，那么请求者可以在发出下一个写操作之前等待前一个写操作完成（completion）。这种观察顺序通常被称为OWO。CHI协议提供了一种称为“Streaming Ordered Write”的机制，以更高效地传输此类有序的写操作。

Streaming Ordered Write机制依赖OWO保序要求和CompAck的使用。当使用Streaming Ordered Write时，请求者和HN-F的职责如下：

请求者必须将请求的Order字段设置为0b10，并设置ExpCompAck。写请求的OWO向HN-F表明，此写操作的一致性动作的完成不应依赖于后续写操作的一致性动作的完成。请求者必须在发送下一个写请求之前等待DBIDResp、DBIDRespOrd、CompDBIDResp或Comp响应。请求者在接收到DBIDResp、DBIDRespOrd、CompDBIDResp或Comp响应以及所有先前有序写操作的Comp或CompDBIDResp响应后，必须发送一个CompAck响应。如果要发送写数据，请求者可以（但非必须）将CompAck与WriteData合并为NonCopyBackWriteDataCompAck响应。当请求者使用合并的CompAck和WriteData响应处理一个事务时，必须为该事务中的所有WriteData传输都发送合并响应。接收了DBIDResp* 并准备发送CompAck的请求者不应等待Comp发送CompAck。HN-F在释放写事务并使写操作对其他观察者可见之前，必须等待请求节点发送CompAck响应。

下图，这种流程能够避免在 Write-A 完成之前，读操作就获取到Write-B的新值。

2.2 Optimized Streaming Ordered Write：

本节的写只适用于WriteUnique和WriteNoSnp事务。Streaming Ordered Write可以进一步优化：如果之前发送的写操作的target不同，那么请求者在发送下一个有序写操作之前无需等待DBIDResp*响应。在实际实现中，CMN的RND或RNI在收到相同AWID的写操作时，默认都会连续发送写请求，不用等待DBIDResp*响应，在发送NonCopyBackWriteData时，需要等收到之前写请求的Comp后才能发。

OWO写可以由多个请求者共同使用，通过使用WriteDataCancel消息来避免与资源相关的死锁和活锁问题。