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

71–80 of 103 posts

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

#71

Post by marshray »

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…

> the set of locks that a thread holds is basically an implicit dynamically-scoped global variable that can affect the correctness of the program

One technique to get a handle on this situation is making the mutexes actual explicit global variables.

"But global variables are bad" they will say. Yeah. And it reflects the reality.

"But I need a separate mutex for each object instance like they recommended in 1995 https://docs.oracle.com/javase/tutorial/essential/concurrenc... " they will say. Have fun with that.

Python and early Linux kernels use a single global mutex for access to all shared mutable state. In my experience, this is an entirely reasonable design decision for a huge majority of applications.

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

#72

Post by yellowapple »

J-Kuhn wrote: post #4
Roboprog wrote: post #3

The source of the article, Sun, is interesting. I guess the author knew what was about to be foisted upon the world. Kudos for trying to warn us. (I remember reading Novell and OS/2 documentation in the late 80s / early 90s about threads and recoiling in horror. Of course, all real men must use threads, cuz they’re faster, even if stupefyingly dangerous)

John Ousterhout is the inventor of the Tcl language.

Which includes Tk, notable for being a relatively-easy-to-use GUI toolkit that embraces events as described in these slides.

(You probably already know this; just elaborating for those who might not be familiar with Tcl/Tk)

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

#73

Post by mchahn »

indigochill wrote: post #38
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…

There's even a course from GA Tech (Intro to Operating Systems, publicly available on Udacity) that covers how to use threads safely and sanely. I went in knowing nothing but terror from a failed experiment in naive multithreading and came out wanting to apply threads to everything. Maybe not quite the right approach, but I at least feel vastly more confident with keeping them manageable. Like you say, managing how a…

> covers how to use threads safely and sanely.

It takes a lot less expertise to make events as fast as threads as it takes to make threads as safe as events. I don't know about the rest of you, but I personally do not have a brain that can become an expert on every topic.

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

#74

Post by hodgesrm »

J-Kuhn wrote: post #4
Roboprog wrote: post #3

The source of the article, Sun, is interesting. I guess the author knew what was about to be foisted upon the world. Kudos for trying to warn us. (I remember reading Novell and OS/2 documentation in the late 80s / early 90s about threads and recoiling in horror. Of course, all real men must use threads, cuz they’re faster, even if stupefyingly dangerous)

John Ousterhout is the inventor of the Tcl language.

He also has a new book "A Philosophy of Software Design" that is short and worth reading. (I'm currently on chapter 7.)

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

#76

Post by perl4ever »

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 just rewrite an expensive task so that it explicitly processes a chunk that takes a limited amount of time...which also helps with running out of resources in many cases.

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

#77

Post by squirrelicus »

jstewartmobile wrote: post #67
squirrelicus wrote: post #62

Earlier quoted context omitted.

What does multiprocessed model have to do with the "async cult"? And who exactly is in the async cult? Because "async" to me means "async io" like epoll, kqueue etc, which are pretty much necessary to go from ~100 concurrent connections to ~10000 in a performant manner. That will never go away while we're on x86-based architecture.

Async cult (mostly node people) proseltyzing that promises/callbacks are the one true way while glossing over many many scenarios where that execution pattern is less than desirable. Wasn't projecting async all the way down to IO primitives. Commented because most of the debate seems to be threads vs callbacks--with processes being unwisely overlooked.

Interesting. Fundamentally, in order to achieve async io, a continuation is necessary. Syntax may hide this (e.g. async/await), or make it apparent as in callbacks/promises. I can't blame JavaScript for not having syntax that makes async pretty.

That being said, if we're talking not about IO, but about cpu/memory bound problems... Well I'd be lying if I said it was uncommon in my career to come across people who assumed, to the detriment of simplicity, quality, and performance, that a calculation (e.g. process a list mapping op with AsParallel/parallelStream) would be aided by parallelism. That is just ignorance by Dunning-Kreuger devs who don't apply a critical eye to their own experiences.

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

#78

Post by rurban »

insulanus wrote: post #47
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 l…

Threads are good, shared state is good if hidden behind a proper protocol, just locks are evil. Windows and POSIX are to blame.

Nowadays nobody should use locks anyway, as there are much better, faster and safer variants for concurrency with native threads, based on actor capabilities and ownership, and avoid blocking IO like hell. No, not Rust. Rust did it wrong.

Those who do it right are so far Pony, Midori/Singularity, and parrot with native kernel threads. With simple green threads there are some more, but they are only usable for fast IO, not fast CPU tasks.

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

#79

Post by jstewartmobile »

squirrelicus wrote: post #77
jstewartmobile wrote: post #67

Earlier quoted context omitted.

Async cult (mostly node people) proseltyzing that promises/callbacks are the one true way while glossing over many many scenarios where that execution pattern is less than desirable. Wasn't projecting async all the way down to IO primitives. Commented because most of the debate seems to be threads vs callbacks--with processes being unwisely overlooked.

Interesting. Fundamentally, in order to achieve async io, a continuation is necessary. Syntax may hide this (e.g. async/await), or make it apparent as in callbacks/promises. I can't blame JavaScript for not having syntax that makes async pretty. That being said, if we're talking not about IO, but about cpu/memory bound problems... Well I'd be lying if I said it was uncommon in my career to come across people who assu…

You're focusing on performance. Performance is not the world. Parallelism is not the only reason to use cooperating processes. There are other considerations--like task fairness, and isolation.

We desperately need more isolation in software.

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

#80

Post by pjmlp »

bunderbunder wrote: post #48

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…

3. Work on a task handled by a thread pool, like scalable software

4. Work on another process, like safe software

Post reply on HN