Hacker News Reader

Comment by taneq | Hacker News Reader

Basic rules for multithreading:

1) Don't. You don't need to.

2) Still don't.

3) If you really, really do need threads, keep it as simple as possible and make sure that every access that needs to be synchronized, is synchronized.

I've been programming for a long time now and I've seen precious few cases where multithreading is legitimately a better option, let alone the only option. Usually even then it's just about using more cores.

View on HN

This is quite poor advice. With Moore's law slowing down multithreading is an important skill for almost any developer to learn.

Even then threads are rarely the correct architectural abstraction for your code. Something like a work stealing job scheduler that happens to have spun up to the same number of worker threads as cores on the system under the hood generally works way better. That is, there should ideally be only one line in your code base that says "new Thread()" or the like.

But in the end, your program is still using threads. So the "don't use threads" mantra fails.

There's "using threads at all" and there's "using threads as component of your exported architecture". The vast majority of your code should work if there's one worker thread or a hundred. You shouldn't be using threads to save state while some long running IO operation blocks you for instance. Even if you have computationally expensive work that screams threads, you should split them into small jobs backed by a priority queue anyway because that's how you most effectively distribute work regardless of one core or many.

A thread pool can have two threads pick up the task and run it concurrently. What you're talking about is basically an event loop that runs one task at a time (on any core ) giving you sequential execution.

How about: Use threads, but only in scenarios when it's simpler or when you need to execute on multiple cores on parallel.

Lol 3) is such generic advice. It's like "keep your doors locked ". A bunch of things may need atomic updates. Message passing is probably the easier approach.

So don't, unless you need to, and then it's OK?

Yes, but in many many cases where people think they need to, there's actually a simpler and safer way to do it. Too many programmers see a long running task or an unresponsive UI and immediately declare that threads are the answer, when they're almost always not.

Admittedly they're much more likely to be useful now with so many spare cores on every machine, but they're still a hammer when most problems are screws.

How is anything other than threads supposed to be a solution to long-running tasks blocking the UI thread?

Which long running tasks?

Blocking IO? Switch to non blocking and events.

Long running computationally expensive work? Break it into small jobs and have your job queue be a priority queue.

At that point you're correct regardless of if you've got one thread or many servicing the queue. And generally the best way to take advantage of multiple cores os to have it be totally agnostic to the number of cores it's running on like this anyway.

IHMO, threads are mostly useful for scaling a workload beyond the capacity of a single core. For all other types of concurrency problems, a single thread of execution using some kind of event loop is usually a better fit.

Be reluctant to use threads.

"Cautious" is probably a better word. Be cautious when considering threads.

It is amazing how often I've seen developers reach for threading when it really wouldn't solve their particular problem. The downsides regularly outweigh the benefits.

But you have to use threads at least once in your career, and until you've done that there will always be an unresolved tension.

Reply on news.ycombinator.com