Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Threads Are a Bad Idea (1995) [pdf]

cc.gatech.edu

Post reply on HN
Print view View original

51–60 of 103 posts

Re: Why Threads Are a Bad Idea (1995) [pdf]

#51

Post by bartread »

Also, I have bad news for you if you are a web developer: unless all you're serving up is HTML (either static or generated on the server[1]) you are developing a multi-threaded app - it just happens to be the case that the threads are running on different machines. Race conditions between client and server code are a thing, so you'd do well to understand the concepts of multi-threading.

[1] And even in this case you're probably still multi-threaded, although in most cases it won't feel like it because your server side threads won't share state.

Re: Why Threads Are a Bad Idea (1995) [pdf]

#52

Post by pjungwir »

I've built things with pthreads a few times, and also used threading in Java, Rust, Python, and Ruby. (Edit: C# and Perl too IIRC. :-) The best book I've read about using threading safely was the O'Reilly Java Threads book. It's been about 16 years, but I remember it being a great "teaching the concepts" book, taking you through lots of pitfalls and showing how many ways you can mess up. It taught me way more than just Java. Like oldgeezr I kind of roll my eyes at the "you must be this tall to use threading" stuff, but I think I largely owe to that book both my confidence and my wariness. I bet it is still worth reading today.

Re: Why Threads Are a Bad Idea (1995) [pdf]

#53

Post by cautionarytale »

geezerjay wrote: post #41
cautionarytale wrote: post #26

A serious practical problem with threads mirrors the same problem with C++, which is that many programmers reach for it first when they should be reaching for it last . Both of these technologies are like swallowing glass, and the wise programmer will avoid them if at all possible.

> that many programmers reach for it first when they should be reaching for it last. What's the go-to solution to get a UI to not block when running a computationally expensive task that takes a lot of time to finish?

Put the computationally expensive task in its own process, and have the UI monitor it as needed as part of its event loop.

(That won't work in every case, but it should be thoroughly considered first.)

Re: Why Threads Are a Bad Idea (1995) [pdf]

#54

Post by cautionarytale »

stochastic_monk wrote: post #46
cautionarytale wrote: post #26

A serious practical problem with threads mirrors the same problem with C++, which is that many programmers reach for it first when they should be reaching for it last . Both of these technologies are like swallowing glass, and the wise programmer will avoid them if at all possible.

It depends on your field. If your area of expertise is high performance software, C++ can be the right choice for most of your problems.

It is, and I go there only as needed.

Re: Why Threads Are a Bad Idea (1995) [pdf]

#55

Post by outworlder »

Under Linux, you don't need threads. Threads and processes are basically the same thing. You just provide different flags which tell the kernel how it should view that process, which will impact things like memory isolation, copy on write, etc.

Under Windows, it is a different story. Threads and processes are wildly different constructs, and threads are more lightweight. Sometimes, still not lightweight enough, so they came up with fibers.

Re: Why Threads Are a Bad Idea (1995) [pdf]

#56

Post by pjungwir »

bartread wrote: post #49
oldgeezr wrote: post #24

Oh gee I guess I'm a wizard. Lots of systems/embedded programmers roll their eyes at this kind of talk. Threads aren't really that hard. Event queues do have benefits in certain situations. They pair nicely with state machines. You can easily end up in callback hell though, and it is often difficult to integrate some long-running, atomic tasks into your event loop. You end up doing things like having a thread pool, a…

Quite. I'm so fed up of the "threads are bad" argument (in my mind it's been commonplace since about 2008, so it's interesting to see this piece from 1995). I've made use of threads at some point in almost every single job of any duration. They're one of many problem solving tools and if you understand them, which isn't particularly difficult, at some point you're bound to run into a problem that's a natural fit for…

It reminds me of a critique of threads in The Art of Unix Programming (available at http://www.catb.org/esr/writings/taoup/html/ch07s03.html#id2...). And now that I look it up, it actually cites the Ousterhout paper! This suspicion of threading was one of the few parts of that book I found unconvincing, personally, but it's another witness that they have worried some people for a long time.

Re: Why Threads Are a Bad Idea (1995) [pdf]

#57

Post by dottrap »

geezerjay wrote: post #41
cautionarytale wrote: post #26

A serious practical problem with threads mirrors the same problem with C++, which is that many programmers reach for it first when they should be reaching for it last . Both of these technologies are like swallowing glass, and the wise programmer will avoid them if at all possible.

> that many programmers reach for it first when they should be reaching for it last. What's the go-to solution to get a UI to not block when running a computationally expensive task that takes a lot of time to finish?

I don't claim these are "go-to" solutions, but only that there are multiple solutions to pick from.

One solution is processes (mentioned in the post). Fork a process which does your computationally expensive thing and then get the result when you are done. For the security minded, we've seen this make a bit of a come back because separate processes can be run with more restrictions and can crash without corrupting the caller. We see this in things like Chrome where the browser, renderers, and plugins are split up into separate processes. And many of Apple's frameworks have been refactored under the hood to use separate processes to try to further fortify the OS against exploits.

Another solution is break up the work and processing in increments. For example, rather than trying to load a data file in one shot, read a fraction of the bytes, then on the next event loop, read some more. Repeat until done. This can work with both async (like in Javascript) or you can do a poll model. Additionally, if you have coroutines (like in Lua), they are great for this because each coroutine has its own encapsulated state so you don't have to manually track how far along you are in your execution state.

Re: Why Threads Are a Bad Idea (1995) [pdf]

#58

Post by outworlder »

bartread wrote: post #49
oldgeezr wrote: post #24

Oh gee I guess I'm a wizard. Lots of systems/embedded programmers roll their eyes at this kind of talk. Threads aren't really that hard. Event queues do have benefits in certain situations. They pair nicely with state machines. You can easily end up in callback hell though, and it is often difficult to integrate some long-running, atomic tasks into your event loop. You end up doing things like having a thread pool, a…

Quite. I'm so fed up of the "threads are bad" argument (in my mind it's been commonplace since about 2008, so it's interesting to see this piece from 1995). I've made use of threads at some point in almost every single job of any duration. They're one of many problem solving tools and if you understand them, which isn't particularly difficult, at some point you're bound to run into a problem that's a natural fit for…

> which is when locking becomes essential, most languages and platforms have easy to use constructs to help you do this without much in the way of drama.

This is actually a problem. It is very easy to just slap locks around which, depending on your workload, can cause the threads to be blocked waiting for work.

I have seen many designs that used threads "for performance", but had so many locks in place that a single threads would actually perform similarly, with much less code complexity.

Once you get past a couple of locks in your code, it starts to smell.

Just because you can do Thread.New in your favorite language, doesn't mean you are using them correctly or efficiently.

Re: Why Threads Are a Bad Idea (1995) [pdf]

#59

Post by dgreensp »

Threads were overprescribed in the 90s. I’m pretty sure the original example code for drawing an image in Java involved typing “new Thread” so that the image could be loaded over the network in the background. Truly the way to write apps in the Internet age!

At the same time, Java’s threads are so easy to use — without of the portability or debuggability issues of native threads — that threads don’t seem that bad to Java programmers. Yeah, shared state can be a foot gun, but so can global variables. You just keep things as pure and easy to reason about as possible. And Java has had concurrency primitives that keep you from having to deal directly with threads and locks for over a decade.

I don’t think “events” and threads solve the same problem. If your program would work just as well doing all its work in a single thread then yeah, you don’t really need threads. If we’re comparing “events and callbacks” async style to async/await style where you write your code as if it were running in a thread (even if it isn’t), I think the latter wins.

Post reply on HN