On Wed, Oct 26, 2016 at 09:18:02PM +0200, David Herrmann wrote: > A bus1 message queue is a FIFO, i.e., messages are linearly ordered by > the time they were sent. Moreover, atomic delivery of messages to > multiple queues are supported, without any global synchronization, i.e., > the order of message delivery is consistent across queues. > > Messages can be destined for multiple queues, hence, we need to be > careful that all queues get a consistent order of incoming messages.
So I read that to mean that if A and B both send a multi-cast message to C and D, the messages will appear in the same order for both C and D. Why is this important? It seem that this multi-cast ordering generates much of the complexity of this patch while this Changelog fails to explain why this is a desired property. > We > define the concept of `global order' to provide a basic set of > guarantees. This global order is a partial order on the set of all > messages. The order is defined as: > > 1) If a message B was queued *after* a message A, then: A < B > > 2) If a message B was queued *after* a message A was dequeued, > then: A < B > > 3) If a message B was dequeued *after* a message A on the same queue, > then: A < B > > (Note: Causality is honored. `after' and `before' do not refer to > the same task, nor the same queue, but rather any kind of > synchronization between the two operations.) > > The queue object implements this global order in a lockless fashion. It > solely relies on a distributed clock on each queue. Each message to be > sent causes a clock tick on the local clock and on all destination > clocks. Furthermore, all clocks are synchronized, meaning they're > fast-forwarded in case they're behind the highest of all participating > peers. No global state tracking is involved. Yet the code does compares on more than just timestamps. Why are these secondary (and even tertiary) ordering required?