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

41–50 of 103 posts

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

#41

Post by geezerjay »

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?

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

#42

Post by jstewartmobile »

pjmlp wrote: post #19

Yep, they might be a good solution on resource constrained hardware, but we learned hard how bad they are from security and stability point of view. In that regard process are much better solution.

I suspect today's downvotes will be tomorrow's i-told-you-so points. The async cult's days are numbered.

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

#43

Post by AnimalMuppet »

nine_k wrote: post #15
girzel wrote: post #8

Just FMI: the "events" approach that's recommended in the article over threads, that's how Python libraries like tornado and twisted work, right? And to what extent does the new asyncio Python library assume that functionality?

Events don't share mutable state (at least implicitly), they carry a copy of data. This eliminates a huge class of thread-related errors. The canonical thing that works this way is Erlang (and its modern cousin, Elixir). See also "actor model" (e.g. Akka). It is approximately how Windows and Mac GUI used to work (back in the day; did not look at these APIs for ~20 years). Python async is coroutines, a different kind…

> Events don't share mutable state (at least implicitly), they carry a copy of data. This eliminates a huge class of thread-related errors.

I'm not sure that's true, at least not in my problem space. Copying data leaves you the possibility of operating on stale data, which will result in the computation returning the wrong answer. To avoid that, you have to let the event handler know somehow when the data has changed. How are you going to do that?

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

#45

Post by kjeetgill »

nostrademons wrote: post #40
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…

Systems/embedded programmers roll their eyes at this kind of talk because they usually control (or at least have visibility into) all of the code that goes into their stack. Threads aren't that hard under these conditions. The main problem with threads is that they're non-composable: the set of locks that a thread holds is basically an implicit dynamically-scoped global variable that can affect the correctness of the…

I agree with both of you. I don't think threads are THAT hard to work with. It definitely takes some experience to do it well and quite a bit more documentation to maintain the expected invariants. When libraries can get into a tangle, it's usually code that's in house and better ripped out. Easier said than done I know.

Open libraries tend to either just be single threaded abd should be used as such or explicitly thread-safe.

Disclaimer: Used threads in Java not much in C. Love me some Jsr-133 volatiles. Still confused with the Java 9 memory model updates.

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

#46

Post by stochastic_monk »

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.

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

#47

Post by insulanus »

rother wrote: post #36

I was not coding in 95, and therefore don’t understand the perspective of the author back then, but it seems clear from the presentation that the culprit was “shared mutable state”, not “threads”. Wasn’t functional programming a thing back then?

Yes, but threads (the popular APIs - eg. POSIX threads, Win32 Threads) imply the availability of of shared mutable state, concurrency, and custom written locks. And when something is available, it will be used. Heck, you could even pass a pointer to an address in some other thread's stack with ease.

The amount of experience you needed to program that, while dealing with structuring the rest of your program could be large, especially if you were adding threads to an existing program.

Functional programming is cumbersome to pull off in the systems programming languages available at the time (C).

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

#48

Post by bunderbunder »

Oh, to return to what life was like 23 years ago, when GUI applications were so simple that you could get away with fitting all their work onto a single thread.

Nowadays, a great many GUI apps have a lot of data crunching to do in the background. You've really got two options for how to handle that:

  1. Be intermittently unresponsive, like iTunes.

  2. Do work on a background thread, like decent software.
(Intentionally omitting the option of breaking your work into a bunch of tiny bits that can be handled on a single thread's event queue like some sort of deranged node.js app from hell, on the grounds that please no I can't even.)

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

#49

Post by bartread »

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 a multi-threaded solution.

Nowadays, especially with no shared state, they're super-easy to use on many platforms. Take, for example, the parallel support in the .NET framework, along with functionality that supports debugging multi-threaded apps in Visual Studio like the ability to freeze threads.

If you do need to share state, 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.

I'm not suggesting for a minute that there are no dangers, but there are plenty of dangers with other programming techniques, as well as lurking in any system of sufficient complexity, so I don't really understand why threads garner so much hate.

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

#50

Post by kjeetgill »

ModernMech wrote: post #30
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…

A lot of work in programming languages over the past decade has been devoted to providing a safety net and guard rails for avoiding the pitfalls of thread-based concurrency. See in particular Rust and Go. It's still quite possible to corrupt data and get deadlocks, but our languages have come a long way to making it harder. But the point of this article is to say if we ditch the notion of threads entirely and go with…

I love go and goroutines, but besides the ability to select() over channels I wouldn't say go has done much to help get concurrency _right_. Mostly just easier. Even Java has a few more tools for healthy concurrency.

I don't blame go because I'm not convinced threads are all that bad, but having more concurrent data structures would be great.

Post reply on HN