News for hackers. Stuff that matters.
Re:Bus1 – Kernel Message Bus by solidsnack9000 on Wednesday October 26, 2016 @09:18PM (#12802192)
> Also in the case where there can be no causal relationship, we are guaranteed

> a global order. In case two events happend concurrently, there can never be

> any inconsistency in which occurred before the other. By way of example,

> consider two peers sending one message each to two different peers, we are

> guaranteed that both the recipient peers receive the two messages in the same

> order, even though the order may be arbitrary.

How could that possibly work?

Re:Bus1 – Kernel Message Bus by sciurus on Wednesday October 26, 2016 @09:31PM (#12802237)
Re:Bus1 – Kernel Message Bus by mfukar on Thursday October 27, 2016 @05:57AM (#12803907)
With their "synchronize-local-clocks" approach, it doesn't.

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".

Re:Bus1 – Kernel Message Bus by tomegun on Thursday October 27, 2016 @07:36AM (#12804262)
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?

Re:Bus1 – Kernel Message Bus by mfukar on Thursday October 27, 2016 @07:52AM (#12804322)
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.
Re:Bus1 – Kernel Message Bus by mfukar on Thursday October 27, 2016 @11:11AM (#12805731)
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.
Re:Bus1 – Kernel Message Bus by mfukar on Friday October 28, 2016 @08:01AM (#12814941)
It is indeed. Cool applications too. I remember at least GUN - a graph db engine - uses them to great effect, and its author hangs out here, iirc.