Why Threads Are a Bad Idea (1995) [pdf] • Hacker News Board

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

#101

Post by Roboprog » Thu, Jun 14, 2018, 3:33 AM UTC

pvg wrote: post #7

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)

The author is John Osterhout, a CS professor. He was working at Sunlabs at the time. It's not like some unknown lone voice from the bowels of Sun was 'trying to warn us'. Warn us about what, anyway?

“Threads are a bad idea” I believe is the warning.

And Sun was busy rolling out a certain now popular language with threading baked in around 1995.

I’ve had to fix other people’s servlet thread crosstalk bugs a few times. Wish “modern” (???) web apps used a different architecture...

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

#102

Post by Roboprog » Thu, Jun 14, 2018, 3:35 AM UTC

yellowapple wrote: post #72

J-Kuhn wrote: post #4

Earlier quoted context omitted.

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)

I’ve not used tcl/tk since around 2000, but it was a nice thing to quickly code up some dialog boxes for operations oriented scripts back in the day.

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

#103

Post by Roboprog » Thu, Jun 14, 2018, 3:44 AM UTC

Roboprog wrote: post #6

twtw wrote: post #2

> Only use threads where true CPU concurrency is needed. This is the case much more often now than it was in 1995.

Somebody better tell the Node.js cluster guys :-) They manage without threads pretty well, I think. Shared state is deliberate, outside of individual processes, rather than accidental in-process. As it should be unless you are doing some serious systems level programming.

Gotta love the downvotes. So, it’s offensive to suggest that there are alternatives to threading on a post about WHY threading IS a bad idea???

Actor model with messages (events) sent between potentially isolated processes, perhaps?

If you truly need to run a compute intensive task in the background, the effort to [de]serialize a “command object” to and from another process should not be much overhead, vs sharing almost all memory by default.

Once you reach the point where you are starting a thread pool at start up, rather than spawning threads on demand, why not just have a process pool?

Shared memory blocks can also be used to explicitly share data too large to effectively serialize as a message / event.

If you truly have something that pumps huge amounts of data between compute intensive tasks, then threads make sense. Proceed with extreme caution, and try to encapsulate the trick bits.