5 ms·

> 1. No shared memory. I'd rather say "no reliable message delivery". The only difference between completely reliable messaging and shared memory is performanc

• jayd16 6y ago
  I don't agree with this. Reliability and transactional/atomic reads and writes are different things. "Reliable" is also a vague value judgement. "Shared memory" implies data coherency.
  • DSingularity 6y ago
    I think the distinction he is trying to raise is that messages can be lost in distributed systems. Building distributed shared memory is possible but expensive (readers must write, writers must broadcast). That is why he is raising that distinction and I think it is a good one to raise.
  • zvrba 6y ago
    > "Reliable" is also a vague value judgement 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.
• AtlasBarfed 6y ago
  The discussion is kind of walking around the CAP triangle at this point.
  • inopinatus 6y ago
    Distributed system, n. Any computing structure that produces CAP-theoretic bickering when discussed. See also: halting problem.
    • rualca 6y ago
      That's pretty funny and clever. Thanks for the chuckle.
• mav3rick 6y ago
  Your second point is moot. Even in a multi threaded single machine program you can load state and have it changed by another thread. That's bad design and not a distributed system characteristic.
  • omginternets 6y ago
    >Even in a multi threaded single machine Multiprocessors are distributed systems. (See my other comment: https://news.ycombinator.com/item?id=26093556 https://news.ycombinator.com/item?id=26093556)
    • mav3rick 6y ago
      2 threads can run on 1 core (without HT) sequentially and this problem can still exist. More commonly if you don't have the right locking.
      • omginternets 6y ago
        Yes, and from this we can conclude that single-core processors are distributed systems too! It's counter-intuitive from an architectural (i.e. teleological) perspective, but it makes perfect sense when you approach it from a suitable level of analysis (intentionality).
        • mav3rick 6y ago
          It doesn't because memory is shared, clock is shared. Some of the tougher challenges in DS don't reside in this situation.
          • omginternets 6y ago
            >It doesn't because memory is shared, clock is shared. 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.
• joshuak 6y ago
  No reliable message delivery, does not help define distributed systems because it can be broken down into a more fundamental elements that are required to guarantee that reliability. 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.
  • zvrba 6y ago
    You're not coherent. > 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.