Not the person you were asking the question to, but I can give you tons of examples. This is particularly true in the embedded space or people who write C or C++ that doesn’t have any standard event library. Basically, threads are a lowest-common denominator way to do blocking operations without stalling everything. I’ve seen a lot of code where there’s various threads running at different intervals (low priority background thread that sleeps for 1 second then wakes up to do stuff, another thread that does nothing but blink an LED, etc.) But in reality, in most non-cpu bound workloads, using an event loop would make writing this kind of code much easier and you woulnd’t ever have to worry about mutexes, semaphores, deadlocks, etc. As a C++ programmer, using Qt (even for non-UI stuff) with its event loop is just so much easier than spinning up threads just to call a network endpoint.

That being said, threads definitely have their place and are the only real way to take advantage of all the power offered by modern multi-core CPUs (well that and multi-process but that’s not really any easier to get right). But for the basic stuff I think running 80 threads when your app is only using 5% cpu is insane (something I see a lot in the C++ code I’m exposed to).

Aren't all your examples still examples of concurrency?

> way to do blocking operations without stalling everything

Switching between multiple tasks doing IO - that's concurrency isn't it?

> various threads running at different intervals (low priority background thread that sleeps for 1 second then wakes up to do stuff

Different tasks ready to run and switching between them as needed - that's concurrency again isn't it?

Not really sure what everyone else in this thread is seeing that I'm not.

OK, sure those are actually examples of concurrency. I was thinking of concurrency more along the lines of multiple threads of execution doing useful work at the same time, which threads are actually good at doing but these examples are not that.

The confusion might be due to everyone using concurrency to mean concurrency and/or parallelism.

Think of an object oriented system. You can have a thread per object at the extreme where each object has its own thread/queue to handle messages. For most cases with synchronous calls you’re not really getting any concurrency.

Maybe it’s hard to imagine now, but in the 80s and 90s there were people that pushed this sort of architecture with a straight face. Even if not this extreme the idea of using threads for componentization rather than a focus on concurrency..which was possibly a side benefit was very much a thing (think COM/CORBA))

Hence why many articles like this and Ousterhout from the 90s, etc saying it was idiotic.

I worked on an embedded system with 1 thread per object and it was a very good ratio of code-to-expressivity (both when being used, and the implementation of the system). Each logical hardware port had its own thread, and was interacted with solely through message passing.

This is pretty much exactly the kind of robust system architecture that Erlang advocates employ.

In embedded systems, our kernels and threads are lightweight enough that we can go very fine-grained without paying a steep context-switching penalty. I'm not convinced that the penalty in Linux is all that high, either. Its only when you're going after the C10K (or C1M?) problem that you start to notice.

> In embedded systems, our kernels and threads are lightweight enough that we can go very fine-grained without paying a steep context-switching penalty.

Right, this system would run through the entire runlist at several kHz when idle and 0.5-1kHz under load on a PowerPC 405 that ran at about 200MIPS. Our shortest deadline was 10ms so it was plenty fast enough. Context switch was swapping out 12 machine words.

>why would you write a program to use threads if you don't need concurrency?

... exactly. There is no good reason. That's what I'm saying the point of the article is. However, this doesn't mean that people don't do it. He is saying that the tasks that people typically use threads to solve can actually be solved with an event loop and handlers, thus eliminating all of the messy issues with shared state, race conditions, etc. that true concurrency introduces.

I think that is referring to the case of "select() is too confusing, I'll use threads instead so I won't have to think about it."

I think I'd still call that concurrency - you want multiple continuations to preserve state between IO calls.

I think that programmers are quick to jump to concurrency when they want to make something performant as opposed to using other structures, like a cache, or researching other possible solutions, like the HN favorite bloom filter, or other algorithm.