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

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

#81

Post by pjmlp » Wed, Jun 13, 2018, 6:46 AM UTC

Spooky23 wrote: post #29

bitcharmer wrote: post #16

I have seen that argument in the past but somehow still can't see how event-based approach saves us from the headaches of concurrency. If you need to deal with parallel processing (which is relatively often in the real world) you WILL have to face the problems of consistency, visibility and program order. Many languages don't even require programmers to have much exposure to threading mechanics. It's an OS responsibi…

1995 was a different era.

Yep, processes were too heavy for 1995 hardware and threads were seen as the solution for everything.

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

#82

Post by pjmlp » Wed, Jun 13, 2018, 6:49 AM UTC

outworlder wrote: post #55

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 th…

Linux is the exception on how most UNIXes implement threads.

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

#83

Post by pjmlp » Wed, Jun 13, 2018, 6:51 AM UTC

mesozoic wrote: post #75

Must be real wizards these days boys. Today we deal with hundreds of instances of an application each running many threads across multiple cpu cores.

And then spend days trying to understand why there is a deadlock when there is an Eclipse.

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

#84

Post by geezerjay » Wed, Jun 13, 2018, 7:00 AM UTC

dottrap wrote: post #57

geezerjay wrote: post #41

Earlier quoted context omitted.

> 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 th…

> One solution is processes

More expensive to start than threads, and far more expensive and complex and restrictive to move data around. Sounds like with the exception of some specific corner cases, threads are a better solution.

> Another solution is break up the work and processing in increments

Either the tasks aee broken into ridiculously fine-grained bits that are hard to make sense or keep track,or you still get a blocking UI. Furthermore, the solution is computationally more expensive.

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

#85

Post by Roboprog » Wed, Jun 13, 2018, 7:56 AM UTC

geezerjay wrote: post #84

dottrap wrote: post #57

Earlier quoted context omitted.

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 th…

> One solution is processes More expensive to start than threads, and far more expensive and complex and restrictive to move data around. Sounds like with the exception of some specific corner cases, threads are a better solution. > Another solution is break up the work and processing in increments Either the tasks aee broken into ridiculously fine-grained bits that are hard to make sense or keep track,or you still g…

What’s the big O of starting a pool? It’s around 1 either way right?

Presumably the work processing time overwhelms the IPC time.

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

#86

Post by zaarn » Wed, Jun 13, 2018, 7:59 AM UTC

geezerjay wrote: post #84

dottrap wrote: post #57

Earlier quoted context omitted.

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 th…

> One solution is processes More expensive to start than threads, and far more expensive and complex and restrictive to move data around. Sounds like with the exception of some specific corner cases, threads are a better solution. > Another solution is break up the work and processing in increments Either the tasks aee broken into ridiculously fine-grained bits that are hard to make sense or keep track,or you still g…

Processes might be more expensive but they do have advantages.

If you do use a lot of CPU time, spawning a process instead of a thread might not have any noticeable impact at all.

Additionally, IPC isolates the process, meaning it can be more resistant to hostile takeover (if you drop privs correctly) and additionally you avoid any and all shared state that could possible result in unforeseen bugs.

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

#87

Post by zaarn » Wed, Jun 13, 2018, 8:01 AM UTC

Like in almost any functionality of a computer or programming language, it helps to understand them, being aware of the risks and knowing alternative approaches.

Threads can be a bad idea but if you keep in mind what variables you use and guard shared memory, it's fine. Sometimes you might prefer a process instead for security/resistance.

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

#88

Post by MrBuddyCasino » Wed, Jun 13, 2018, 8:40 AM UTC

pjungwir wrote: post #52

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 ju…

Java Concurrency In Practise served the same purpose for me. A very good book indeed.

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

#89

Post by dgsb » Wed, Jun 13, 2018, 11:01 AM UTC

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.

And Tcl had since the beginning an event loop naturally embedded in the core language. http://wiki.tcl.tk/2567 http://wiki.tcl.tk/1527

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

#90

Post by devxpy » Wed, Jun 13, 2018, 11:07 AM UTC

Threads are not hard. In fact, threads are extremely easy to implement.

However, real Threading code is just incredibly difficult to reason, just by looking at it. This makes it easy for you to introduce race conditions without even knowing that there is one!

There is also the fact that locks don't lock anything! They are just a flag, that a any code may choose to ignore.

They are a not an enforcing tool, just a cooperative one.

(More here: https://www.youtube.com/watch?v=9zinZmE3Ogk)

P.S. I created a library, that makes it easier to write safer multiprocessing code

https://github.com/pycampers/zproc