thiago at kde.org
Wed Mar 14 11:17:45 PDT 2012
On quarta-feira, 14 de março de 2012 12.08.33, Colin Walters wrote:
> What I keep coming back to is basically that we could make things
> noticeably better if we dropped the total ordering guarantee. I'm not
> sure at all how to do that sanely though - it could be a negotiated
> "feature" but would people really opt in?
Or, asked differently: who would consciously opt out? Or another question: what
are the use-cases for total ordering?
Here's just a wild idea not completely thought through: use the ordering
semantics found in memory and in the C++11 and C11 standards.
Each message send and each message receive indicate its level of ordering,
which can be:
- relaxed: no ordering applied relative to other messages
- acquire / release: if message M1 is sent before M2 and M2 is sent as
"release", and M2 is received with "acquire", then M1 must have been delivered
already; if "relaxed" message M3 is sent after M2, it *may* be delivered
- sequentially consistent: same as acquire/release, but applies to all
The difference between the latter two appear when there are three processes
Now, I have little idea on how to implement this concretely. It would only
make sense if the many connections all had random-access to the messages being
sent, such as in a shared memory scenario. Doing that with a sequential
channel would require having large buffers to keep the messages received out of
order when an order is required.
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 190 bytes
Desc: This is a digitally signed message part.
More information about the dbus