5 ms·

I'm open to arguments, but right now I feel that threads are (for many uses cases) a poor man's fork. Like threading, forking gives you concurrency but unlike t

I'm open to arguments, but right now I feel that threads are (for many uses cases) a poor man's fork. Like threading, forking gives you concurrency but unlike threading it also gives you isolation. There are plenty of IPC mechanisms available to communicate things back and forth when you need to.

Const-me 8y ago
Right, and forks are poor man's processes. All of them have pros and cons but I think forks are only useful for very exotic use cases. > unlike threading it also gives you isolation. If you want isolation why not launch processes? With forks, that copy-on-write thing can increase total RAM usage by a huge factor, if the parent process writes to RAM a lot. > There are plenty of IPC mechanisms available to communicate things back and forth when you need to. For communicating gigabytes of data back and forth you want shared memory anyway. And even for small messages, with threads IPC is faster (1) they are in the same address space, TLB stays current, context switches are faster (2) In some cases, shared memory enables more efficient user-mode IPC methods like busy waiting and lock-free stuff.
- zzzcpan 8y ago
  > For communicating gigabytes of data back and forth you want shared memory anyway. Not really. You are better off communicating what to do with the data, rather than sharing the data.
  - adwn 8y ago
    > You are better off communicating what to do with the data, rather than sharing the data. Not if you actually want to distribute the work over several cores. Example: Your data is partitioned into 4 segments A, B, C, and D. In step 1, node X processes A&B and node Y processes C&D; in step 2, node X processes A&D and node Y processes C&B. If A, B, C, and D are large, this is a prime example where shared memory trumps message passing in terms of performance. If you think that's a contrived case: dense matrix multiplication behaves like this.
  - pcwalton 8y ago
    Only if you don't have a data-parallel workload. Message passing is often a nonstarter for data-parallel workloads. Another way to look at it is that the hardware has a very efficient word-level message-passing interface built-in, via shared memory. Why not take advantage of it?
    - lmm 8y ago
      > Another way to look at it is that the hardware has a very efficient word-level message-passing interface built-in, via shared memory. Why not take advantage of it? Because shared mutable state is the root of all evil, or at least very difficult to reason about. Better to have clear owners for all state; if you need to conduct multiple operations on the same data you should move the code to where the data is rather than sharing the data between different processing units (this has long been a truism of distributed system design; modern multicore processors behave much the same as distributed systems if you zoom in enough, and the same techniques are appropriate).
      - pcwalton 8y ago
        It may be "the root of all evil", but often there's no faster way to solve the problem. We need to accept that shared mutable state is sometimes necessary and work on how to tame it to be maintainable and usable.
        a1369209993 8y ago
        Shared mutable state is like goto; yes, it is sometimes necessary, but that only happens when there's a deficiency in your language's concurrency primitives.
- sjmulder 8y ago
  All fair points. I didn't really consider creating processes in a non-fork way. I'd probably miss the easy transfer of unnamed shared objects you get with forking. How do unrelated processes usually initiate communication?
  - Const-me 8y ago
    > How do unrelated processes usually initiate communication? They aren't unrelated, they are parent and child. They know PIDs of each other. Parent can read/write stuff to child's streams, input output error. Child inherits opened files. Parent can set command-line arguments & environment variables for the child.

Const-me 8y ago

Right, and forks are poor man's processes. All of them have pros and cons but I think forks are only useful for very exotic use cases. > unlike threading it also gives you isolation. If you want isolation why not launch processes? With forks, that copy-on-write thing can increase total RAM usage by a huge factor, if the parent process writes to RAM a lot. > There are plenty of IPC mechanisms available to communicate things back and forth when you need to. For communicating gigabytes of data back and forth you want shared memory anyway. And even for small messages, with threads IPC is faster (1) they are in the same address space, TLB stays current, context switches are faster (2) In some cases, shared memory enables more efficient user-mode IPC methods like busy waiting and lock-free stuff.

zzzcpan 8y ago
> For communicating gigabytes of data back and forth you want shared memory anyway. Not really. You are better off communicating what to do with the data, rather than sharing the data.
- adwn 8y ago
  > You are better off communicating what to do with the data, rather than sharing the data. Not if you actually want to distribute the work over several cores. Example: Your data is partitioned into 4 segments A, B, C, and D. In step 1, node X processes A&B and node Y processes C&D; in step 2, node X processes A&D and node Y processes C&B. If A, B, C, and D are large, this is a prime example where shared memory trumps message passing in terms of performance. If you think that's a contrived case: dense matrix multiplication behaves like this.
- pcwalton 8y ago
  Only if you don't have a data-parallel workload. Message passing is often a nonstarter for data-parallel workloads. Another way to look at it is that the hardware has a very efficient word-level message-passing interface built-in, via shared memory. Why not take advantage of it?
  - lmm 8y ago
    > Another way to look at it is that the hardware has a very efficient word-level message-passing interface built-in, via shared memory. Why not take advantage of it? Because shared mutable state is the root of all evil, or at least very difficult to reason about. Better to have clear owners for all state; if you need to conduct multiple operations on the same data you should move the code to where the data is rather than sharing the data between different processing units (this has long been a truism of distributed system design; modern multicore processors behave much the same as distributed systems if you zoom in enough, and the same techniques are appropriate).
    - pcwalton 8y ago
      It may be "the root of all evil", but often there's no faster way to solve the problem. We need to accept that shared mutable state is sometimes necessary and work on how to tame it to be maintainable and usable.
      - a1369209993 8y ago
        Shared mutable state is like goto; yes, it is sometimes necessary, but that only happens when there's a deficiency in your language's concurrency primitives.
sjmulder 8y ago
All fair points. I didn't really consider creating processes in a non-fork way. I'd probably miss the easy transfer of unnamed shared objects you get with forking. How do unrelated processes usually initiate communication?
- Const-me 8y ago
  > How do unrelated processes usually initiate communication? They aren't unrelated, they are parent and child. They know PIDs of each other. Parent can read/write stuff to child's streams, input output error. Child inherits opened files. Parent can set command-line arguments & environment variables for the child.