I'd rather say "no reliable message delivery". The only difference between completely reliable messaging and shared memory is performance.
> Because there's no shared memory it's impossible for any one server to know the global state.
Even _with_ shared memory it's impossible to _know_ the global state. Just after you've loaded some data from memory, it can be immediately changed by another thread.
"Reliable" is also a vague value judgement.
"Shared memory" implies data coherency.
It is not. Reliable: message delivery is guaranteed, i.e., the message _will_ eventually reach its intended destination.
> "Shared memory" implies data coherency.
It does not, re. CPUs with weak memory models. Yes, you can insert barriers, but what happens underneath is that HW exchanges a bunch of messages (reliably!) between nodes to bring them to a consistent view of the global state.
See also: halting problem.
Shared memory works well for me because in my mind shared memory means concurrent processes and memory have a common clock and are connected to the same power supply. This avoids confusion around how one handles some parts running while other parts are not.
Since we are attempting to define distributed systems not "concurrent processing", concurrent processing can be used in the definition and memory safety can be assumed. We can say that shared memory represents a known global state between concurrent processes because that problem is solved by the common clock and the tools that concurrent processes use to synchronize.
> in my mind shared memory means concurrent processes and memory have a common clock
You're aware that modern CPUs clock their cores independently? (E.g., AVX512 throttling.) Hence, no common clock.
> and are connected to the same power supply
That's irrelevant. Unused cores get powered down all the time. On x86, the OS can execute HLT instruction when there's nothing to do and the CPU gets woken up by an interrupt.
> This avoids confusion around how one handles some parts running while other parts are not.
What is a "part"? The system's scheduler can suspend a thread for an indefinite amount of time.
> memory safety can be assumed
What does that even mean?
> We can say that shared memory represents a known global state [...]
Except that it's false, every single point can be countered with a single modern multicore cpu.
On an abstract level, distributed computation is a computation where it's possible that a message does not reach its intended destination within a fixed time bound, for any reason.
If you can guarantee message deliver within an arbitrary, but fixed, time bound, you can simulate shared memory. Yes, performance will suck if the time bound is large, but you have an equivalent system. That's how HW works underneath anyway.
Tip: reading Lamport's papers is illuminating. You can also read about cache coherence protocols (e.g., MESI or MOESI) and you'll see that the illusion of shared memory is fundamentally implemented by message passing on HW level. The illusion is pretty much solid precisely because HW has time bounds on message delivery.
Multiprocessors are distributed systems.
(See my other comment: https://news.ycombinator.com/item?id=26093556)
You're arguing your point using the definition that I argue is insufficient. We're running around in circles.
>Some of the tougher challenges in DS don't reside in this situation.
Yes, and others still do. We can definitely agree on the fact that it's an easier variant of DS.