Slashdot Mirror

← Back to Stories (view on slashdot.org)

Threads Considered Harmful

Posted by kdawson on from the history-rhymes dept.

LBR9 writes "James Reinders compares native threads with the goto statement so famously denounced 40 years ago by Edsger Dijkstra. Paraphrasing Dijkstra, he says they both 'make a mess of a program,' and then argues in favor of a higher level of abstraction. A couple of people commenting on the post question whether or not we should be even be treading into the 'swamp of parallelism,' echoing the view recently espoused by Donald Knuth."

9 of 266 comments (clear)

  1. Not exactly a new sentiment by Dr.+Manhattan · · Score: 4, Informative
    See here: Threads are a fertile source of bugs because they can too easily know too much about each others' internal states. There is no automatic encapsulation, as there would be between processes with separate address spaces that must do explicit IPC to communicate. Thus, threaded programs suffer from not just ordinary contention problems, but from entire new categories of timing-dependent bugs that are excruciatingly difficult to even reproduce, let alone fix.

    I use threads a fair amount, because they are there. But I kinda wish path expressions would catch on. Let the compiler sort out the scheduling given the constraints - that's the kind of scut work computers are good for anyway.

    --
    PHEM - party like it's 1997-2003!
  2. I'm All For Getting Rid Of Threads, But... by rsmith-mac · · Score: 3, Informative

    I'm all for getting rid of threads, but what are you going to replace them with? Traditional functional languages may be the most obvious solution, but they're also among the most impractical of solutions. Is there anything else out there that can replace threading needs, without throwing out the book on programming? It seems like what we need hasn't been invented yet.

    1. Re:I'm All For Getting Rid Of Threads, But... by Waffle+Iron · · Score: 2, Informative

      Um, if what you've heard is true, why have threads been in Unix for a very long time?

      In the early 90s, threads were the "next big thing". Around that time Java was being designed, so it ended up oozing in threadedness. Threads were tacked into Unix as an afterthought somewhere around that era to keep up with the latest fads.

      Windows NT was also created in those times. Since threads were seen as the way of the future, the design of Windows NT was heavily focused on threads, and that was touted as making the new OS more "modern". There was not a lot of emphasis on process spawning efficiency since it was assumed that an app needing concurrency would create multiple threads rather than spawn processes.

      CreateProcess was a heavy, slow operation (at least back then, I don't know about recent Windows kernels); I've verified that myself. Windows also lacked a native fork() call for fast process cloning. It was much more efficient to keep a thread pool around inside an app to handle asynchronous inputs than to spawn processes for them.

    2. Re:I'm All For Getting Rid Of Threads, But... by Foolhardy · · Score: 2, Informative

      Just to clarify, NtCreateProcess, the kernel syscall to create a process, is much lighter than Win32's CreateProcess function. NtCreateProcess doesn't even start any threads in the new process or load dependent libraries. CreateProcess includes out of process calls to register with CSRSS, an application compatibility database lookup since XP (so slow that there's a special option on WS2003 to turn it off), tons of registry reads, among other things.

      NtCreateProcess even supports COW fork, by specifying a NULL image to load-- it's the Win32 libraries that aren't designed to support forking. POSIX^W SFU^W SUA processes are much lighter than Win32's and can use the kernel's fork support.

  3. Re:How about "C++ threads considered harmful"? by LizardKing · · Score: 2, Informative

    The articles' author explicitly mentions Erlang as a potential solution to threading issues in other languages. In fact he's mainly concerned about POSIX pthreads, Boost threads, Java threads (and presumably Windows low level thread libraries). As I point out in another post below, I disagree with him lumping Java threads in with those used in most C/C++ libraries, as threading support is integrated into the language along with increasingly sophisticated locking support in the library which can be used if the simple object lock is insufficient. In my experience, most data shared across threads is immutable (read only), and the Java libraries encourage use of immutable types such as String. Once you appreciate the value of immutable types, then they can be used just as easily in C++ (with C it's a little harder). Writable shared data can be cleanly hidden behind a decent interface, with the locking within the getters and setters, but again, this approach is applicable in C++ as well as Java.

  4. more detailed analysis from two years ago by somepunk · · Score: 2, Informative

    By Edward Lee of the EECS department at Berkeley: http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.html. Worth reading if you work with threads.

    --
    Those people who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)
  5. Web server w/o processes OR threads... by Dr.+Manhattan · · Score: 3, Informative

    Unix's select/poll mechanism avoids all that. See, e.g., here.

    --
    PHEM - party like it's 1997-2003!
  6. Re:Right. Mod parent up. by LizardKing · · Score: 2, Informative

    If you're familiar with CORBA, and underwhelmed by SOAP, then you might like to check out ICE. It's an attempt to do CORBA "better" - in other words, without the designed by committee and everything bar the kitchen sink aspects that ruined CORBA. I was initially a little bit sceptical, but having played around with it for a notifications system I've become really impressed.

  7. Re:Threads in Windows vs. *NIX by Anonymous Coward · · Score: 1, Informative

    CreateProcess() in Windows is very heavy weight. exec() in *NIX is heavy weight.

    fork() in *NIX is light weight in any modern (post 1980) OS. Doesn't exist in Windows.

    SpawnThread() in Windows is light weight. In *NIX it is a special case of fork()