Are Concurrency Abstractions Emulating UNIX Processes?

Question

OK, I was pondering this today, and I've come to ask for completely subjective and bias opinions on it. Paradoxically, despite this, I don't think it's flame-war fodder either. I think there is room for perfectly civilized conversation -- It's hardly Vim vs Emacs.

I've used a lot of concurrency abstractions, specifically those built on top of threads. There's a big trend among them, whether it be message-passing, immutable-by-default, or thread-local-by-default or other ones.

The trend is that they're all reversing the idea of threads by making data sharing explicit rather than implicit. That is, all data is not shared unless otherwise specified, which is the opposite of traditional threading found in languages like Java. (I know Java supports its own higher-level concurrency abstractions though.) For example, you explicitly pass messages. You explicitly state which variables are thread-local. You explicitly state which variables are mutable. These are just a few examples found in some languages.

I thought this easy style of concurrency was a modern concept. I was mistaken. I started playing around with UNIX toys like fork() and pipe() recently, and I was shocked to discover that effortless, explicit concurrency mechanisms have been around since the start of UNIX.

There's something a little strange about realizing that C + UNIX from the '70s makes concurrency far easier than many modern trendy threading mechanisms.

So, here's what I'm wondering... are these modern thread abstractions simply trying to emulate UNIX-style processes on top of threads, with all of their explicitness and not-shared-by-default traits? I know that some mechanisms like STM offer things like DB-style transactions which is genuinely a modern and innovative solution for concurrency, but most just seem like new ways of doing what UNIX coders were doing a long while back.

Just to say, I'm not a UNIX fanboy, not by any stretch of imagination. I'm aware that processes are far slower than threads to initialize on many platforms, but I'm talking about this from a conceptual basis.

Answer 1

Good observation, there is definitely a trend towards explicit sharing (whether through functional languages or convention). The comment about processes being slower i would adapt a little: they are more heavy-weight, meaning that they are not slower executing in raw performance but every switch between them takes a lot longer than switching between threads. You already recognized that there are some other forms of concurrency and recognize STM. I would only add that there is (in addition to explicit sharing and STM) there is also a growing trend towards thread pooling (task parallel; assign tasks to worker-threads that were started beforehand and recycle them): Definitely the way to go performance-wise and curiously a different approach to explicit sharing because the pooled threads are typically all in one process.

Answer 2

I think it's a less a matter of X emulating Y, than of trying to find a balance.

Completely separate processes keep life relatively simple. They make it fairly easy to build things like pipelines of processes that take at least some advantage of multiple processors. There are some pretty obvious downsides as well though -- particularly lack of flexibility, and quite a bit of overhead.

A single process with multiple threads of execution sharing essentially all resources essentially reverses those: lower overhead and lots of flexibility, at the expense of being more difficult to design and/or keep stable.

For the most part, what's happening is that people are working at finding some middle ground that provides nearly the flexibility and speed of threads, with the simpler design and more stable result of separate processes (and, I think they're largely succeeding, to at least some degree).