
Concurrency ≠ Threads - spydez
http://www.martincmartin.com/blog/?p=84
======
ajross
"But there are other forms of concurrency. Processes that communicate using
files, pipes, sockets, or even shared memory."

I don't see how this solves the problem. It's true that some problems work
well as pipelines where each stage does some finite, balanced amount of work
before passing the data off to the next stage. But many don't.

And I don't follow the files and shared memory argument at all: those are both
shared, unsynchronized-in-the-base-API abstractions _just_ _like_ _threading_.
And they're subject to all the same deadlocks and race conditions. The only
difference is that you use slightly different synchronization primitives (e.g.
fcntl() locks instead of mutex locks).

It's correct to point out that traditional threaded code is difficult to get
right. But it's naive and unhelpful to point to any kind of "secret sauce" as
the solution. The difficulty of concurrency lies in the _problem_ _itself_ ,
not the API.

~~~
sah
_"The difficulty of concurrency lies in the problem itself, not the API."_

Isn't it possible that it's both? Concurrency is hard, but I think the
classical threading model makes it harder. There are simplifications that
really do make it easier to reason about concurrency, like doing all inter-
thread communication via queues, OpenMP-style "parallelize this for loop"
constructs, and pure-functional immutable data structures.

~~~
ajross
Sure. And a reasonable discussion about that stuff and the tradeoffs involved
(queues handlers need to be carefully balanced, for instance, and parallel
loop constructs tend to drown CPUs in locking overhead) would be welcome. But
the linked post was about "threads are bad, use secret sauce instead". There
is no sauce.

~~~
LogicHoleFlaw
I think he is complaining more that so many other people think that threads
_are_ the secret sauce.

------
bayareaguy
For application-level concurrency I really like the way Lua explicitly
excludes the most error-prone and system-dependent concurrency primitives
(preemptive threads, mutexes, semaphores, shared memory, etc) and instead
offers API's for efficient non-preemptive coroutines and states which share no
memory.

------
sah
This paper makes a pretty compelling argument against threads as a model for
concurrency:

[http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1....](http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf)?
[pdf]

------
nailer
"But there are other forms of concurrency. Processes that communicate using
files, pipes, sockets, or even shared memory."

Using multiple single-threaded processes means you're using multiple threads.

What he's saying is true, but he's worded it really clumsily. He's pointing
out alternatives to multithreaded processes, not threads per se.

