Indeed that is how we break ties (not exactly the PID, but you get the idea).
The reason this works is that the only time we can have a tie is if there can be no causality between the events. I.e., the two sending events happen concurrently: the two ioctl calls overlap in time, so there would be no way for one to have caused the other.
What problem do you see with this?
I foresee a problem where people confuse the wording of "total order on all messages" in the wiki to mean there is a "global total order" - in other words, that bus1 solves distributed systems and we can all go home - and building buggy systems on this assumption. I'm not saying the concept is flawed or the implementation buggy, or anything like that.
PS. Neil Brown in the LWN article already conflates "global" and "total" order.
Re:Bus1 – Kernel Message Bus
by jasonwatkinspdx on Thursday October 27, 2016 @10:39AM
(#12805416)
I'd suggest reading the hybrid logical clocks paper.
I have - I'm actually working with it on a multi-version IPC provider (totally unrelated to bus1 & friends). Is it relevant here? I know they're the latest and greatest, but they're not without problems either.
Re:Bus1 – Kernel Message Bus
by jasonwatkinspdx on Thursday October 27, 2016 @07:56PM
(#12811581)
Based on your comments about lamport clocks, etc, I thought you'd find it interesting.
They are using Lamport's algorithm to synchronize the clocks. However, Lamport's approach creates a _partial_ ordering, and to make that a _total_ ordering you need some mechanism to break "ties". For instance, the PID, or whatever.
The catch is that the relationship derived from this arbitrary tie-breaking mechanism has nothing to do with causality, and therefore the total order it imposes is only an artifact of the mechanism chosen.
Finding a tie-breaking mechanism that corresponds to the sending events is, in Lamport's own words, "not trivial".