
The Problem with Threads (2006) [pdf] - DonbunEf7
https://www2.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf
======
jgtrosh
This piece seems to have predicted a very active field in everyday software
development since then.

What are the alternative paradigms that have actually become common use?
Coroutines, async/await, that's what I hear about online but what are others?
I've seen people who touted zmq-communicating-processes with standard patterns
as the solution to all problems, and I'm happy not to have to maintain the
results.

Have we effectively “solved” the concurrency problem, and if so what's left as
an exercise for the future?

~~~
toast0
At risk of being _that guy_ , the actor model (ala Erlang) is pretty good at
concurrency. If you're unfamiliar, it's basically no shared state, and
communication with other actors (Erlang processes) by sending asynchronous
messages to the other actor's message queue.

The code for each actor is usually pretty small and easy to reason about.
However, emergent behavior of the system, and ordering between messages from
multiple actors can become tricky. Also, exposure to this idea long term will
warp your mind :)

~~~
chrisseaton
The actor model is very vulnerable to race conditions - that’s a big downside
to it.

~~~
toast0
It depends on what is racing. If you have the same/dependent information in
two (or more actors), you're going to have a coordination challenge.

So try not to do that. On the other hand, everything that happens with state
within an actor is inherently non-racy, because an actor is sequential code
and no other actor can mess with its state.

------
rectang
I've always liked section 3 of this paper, specifically the concept that
"infinite interleavings" make threads executing in parallel non-deterministic
and difficult to reason about. That gets to the heart of why threaded programs
are so prone to heisenbugs.

 _" They make programs absurdly nondeterministic, and rely on programming
style to constrain that nondeterminism to achieve deterministic aims."_

You can't write an infinite number of test cases for all those interleavings,
and it requires hard thought to suss out where any problems might lie.

~~~
jlarocco
This is just my opinion, but I've never found that part of multi-threading
difficult. Interleaving doesn't matter except where resources are shared
between multiple threads, and the solution is to protect the resource with a
mutex.

Sometimes it's hard to tell when a resource is shared, but that has more to do
with not knowing how the code works than it does with multi-threading.

~~~
typomatic
> Sometimes it's hard to tell when a resource is shared, but that has more to
> do with not knowing how the code works than it does with multi-threading.

With respect, this sort of thing works a lot better for small codebases where
you're the only one working on it. Multithreading when you can't contain the
entire relevant codebase in your brain is where the real challenge is.

