3 ms·

> We know this because there is plenty of real-world evidence that debugging implementations of parallelizing code is worse than merely _difficult_ for humans.

> We know this because there is plenty of real-world evidence that debugging implementations of parallelizing code is worse than merely _difficult_ for humans. Race conditions, deadlocks, livelocks, and insidious data corruption due to subtly unsafe orders of operation plague all such attempts. None of these problems have anything to do with parallelism. But everything with "shared memory multithreading". There are plenty of sane concurrency models implementations out there. Which brings me to this part: > But the truth is, we don’t really know what the “right” language primitives are for parallelism on von-Neuman-architecture computers. We do know what the right language primitives are. Well, at least if you follow concurrency and distributed systems, where it's not even an important question anymore, you just stick to actor model as a default choice and stop caring about these things.

gpderetta 8y ago
>Race conditions, deadlocks, livelocks These have nothing to do with shared memory multithreading. You can easily have all of these with shared nothing distributed systems. >and insidious data corruption due to subtly unsafe orders of operation I'll give you this though.
- zzzcpan 8y ago
  That's stretching it quite a bit. You can implement shared memory multithreading on top of actor model and have all of the same issues. If you don't do that though, you won't have those issues. Same way that you can implement memory unsafe primitives on top of memory safe ones.
  - gpderetta 8y ago
    I have seen deadlocks and race conditions in non shared memory concurrent systems many times. They are no way exclusive of shared memory systems or even more common. They have nothing to do with shared memory and everything to do with message ordering.
    - zzzcpan 8y ago
      It doesn't have to be shared memory specifically, but it has to be concurrent use of something shared even if that something is completely virtual and only exists in your mind. Which then forces you to synchronize access to that something and deal with all those problems. It's not about message ordering though, not unless synchronization is involved.

gpderetta 8y ago

>Race conditions, deadlocks, livelocks These have nothing to do with shared memory multithreading. You can easily have all of these with shared nothing distributed systems. >and insidious data corruption due to subtly unsafe orders of operation I'll give you this though.

zzzcpan 8y ago
That's stretching it quite a bit. You can implement shared memory multithreading on top of actor model and have all of the same issues. If you don't do that though, you won't have those issues. Same way that you can implement memory unsafe primitives on top of memory safe ones.
- gpderetta 8y ago
  I have seen deadlocks and race conditions in non shared memory concurrent systems many times. They are no way exclusive of shared memory systems or even more common. They have nothing to do with shared memory and everything to do with message ordering.
  - zzzcpan 8y ago
    It doesn't have to be shared memory specifically, but it has to be concurrent use of something shared even if that something is completely virtual and only exists in your mind. Which then forces you to synchronize access to that something and deal with all those problems. It's not about message ordering though, not unless synchronization is involved.