4 ms·

> There are problems that exist in distributed system environments that do not exist in single-machine environments. Partial failure, concurrency, and latenc

> There are problems that exist in distributed system environments that do not exist in single-machine environments. Partial failure, concurrency, and latency are three problems that make distributed computing fundamentally different from local computing. IMO this can frame our thinking too much. Concurrency and latency are problems in single systems as well. It would be great to have single systems that handle partial failure, can be updated incrementally, etc. Thinking of 'distributed computing' as a different domain than single system computing is not a useful long term approach. In the end very few systems are 'single machine' systems, if at all - machines are all connected to each other and participate in other, larger, systems.

hinkley 9y ago
Some classes of problems are masked on a single system. For instance, failure of the networking card doesn't preclude the processes from talking to each other. A process that's running on a system that has hung can't make any forward progress so it doesn't care if another process it's talking to is in the same state. Our desktop computers look more and more like clusters in their own right (how many SoCs are inside of your computer right now?). There's a lot of talk lately about having high performance and low power CPUs in the same machine working in tandem. I figure at some point we will start formally treating desktops and laptops like small clusters, at which point these distinctions might start to disappear.
- shalabhc 9y ago
  > Some classes of problems are masked on a single system. Yes but you can also have IPC failure, syscall hang, single thread hang etc. Instead of treating these as special cases, these could be handled by generic patterns that apply to 'distributed computing', if the system was designed similarly.
naasking 9y ago
> IMO this can frame our thinking too much. Concurrency and latency are problems in single systems as well. Right, but every step away from the CPU die you magnify the latency and failure problems by orders of magnitude. Memory is many orders of magnitude higher latency and more susceptible to random bit flips than CPU registers. Another thread's memory is orders of magnitude more expensive still due to cache sync protocols, and more prone to failure necessitating retries due to contention. Another server's data yet more orders of magnitude. At some levels you can ignore latency and failures as practically non-existent, and as you say, in concurrency you can't ignore them but failures are this level are transient. Failures in distributed systems typically persist because the higher latency make retries much more costly, so we look for other shortcuts that typically aren't as effective as solutions employed in concurrency.

hinkley 9y ago

Some classes of problems are masked on a single system. For instance, failure of the networking card doesn't preclude the processes from talking to each other. A process that's running on a system that has hung can't make any forward progress so it doesn't care if another process it's talking to is in the same state. Our desktop computers look more and more like clusters in their own right (how many SoCs are inside of your computer right now?). There's a lot of talk lately about having high performance and low power CPUs in the same machine working in tandem. I figure at some point we will start formally treating desktops and laptops like small clusters, at which point these distinctions might start to disappear.

shalabhc 9y ago
> Some classes of problems are masked on a single system. Yes but you can also have IPC failure, syscall hang, single thread hang etc. Instead of treating these as special cases, these could be handled by generic patterns that apply to 'distributed computing', if the system was designed similarly.

naasking 9y ago

> IMO this can frame our thinking too much. Concurrency and latency are problems in single systems as well. Right, but every step away from the CPU die you magnify the latency and failure problems by orders of magnitude. Memory is many orders of magnitude higher latency and more susceptible to random bit flips than CPU registers. Another thread's memory is orders of magnitude more expensive still due to cache sync protocols, and more prone to failure necessitating retries due to contention. Another server's data yet more orders of magnitude. At some levels you can ignore latency and failures as practically non-existent, and as you say, in concurrency you can't ignore them but failures are this level are transient. Failures in distributed systems typically persist because the higher latency make retries much more costly, so we look for other shortcuts that typically aren't as effective as solutions employed in concurrency.