Talk:Strict consistency
Two things:
(1) Due to the laws of physics this model cannot be used for distributed systems (information would have to travel faster than light) — This is rubbish. You just need to negotiate shared mode on the object. An update will then need to negotiate for exclusive access, so you know you have the latest version for as long as you retain shared mode. Simple. (If slow.) What might easily hold you back is the possibility of failure of a node holding an access privilege, thus blocking progress, but that's nothing to do with FTL.
(2) "Strict consistency" sounds suspiciously like linearizability, only badly phrased — merge the two pages, perhaps?
--Chris Purcell 21:21, 17 June 2006 (UTC)
(1) Imagine some data stored on machine X. Machine Y tries to read that data and thus sends a message to X. Before the message arrives (but after the read message was sent), X changes the data. If X sends the new data value, strict consistency is violated, since the read was issued before the write, but it returned the value after the write. Only with a perfect global clock X could determine that Y issued the read before the data was written and thus send the old value. Perfect global clocks are impossible in a distributed system.
(2) Linerizability does not require a perfect global clock, but a global clock with finite precision.
-- anon
(1) Imagine using a lock. Simply call the "point of action" of the read operation some point when the lock is held. Enough said. "Impossible" is rubbish, unless you add further restrictions (such as wait-free).
(2) Citation please.
--Chris Purcell 12:35, 6 October 2006 (UTC)
(1) Well, you can change the definition as you like (like redefining the "point of action"), but then you are not talking about strict consistency anymore. The way it is defined, it is not possible in a distributed system.
(2) Tanenbaum's book on distributed systems gives a nice overview.
-- anon
I'm not changing the definition, since there isn't one given; if this term actually means something more than linearizability, the page needs some serious fleshing out. Why should 'point of action' mean 'the instant I send a "read" event', and not 'some point in time between calling "read" and it returning a value'? If there are hidden assumptions like this, they should really be defined on the page, not conjured up on demand. The current state of the page is awful: I shouldn't have to read an entire book just to understand a WP entry!