Slashdot Log In
Threads Considered Harmful
Posted by
kdawson
on Fri May 02, 2008 10:03 AM
from the history-rhymes dept.
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."
Related Stories
[+]
Technology: Donald Knuth Rips On Unit Tests and More 567 comments
eldavojohn writes "You may be familiar with Donald Knuth from his famous Art of Computer Programming books but he's also the father of TeX and, arguably, one of the founders of open source. There's an interesting interview where he says a lot of stuff I wouldn't have predicted. One of the first surprises to me was that he didn't seem to be a huge proponent of unit tests. I use JUnit to test parts of my projects maybe 200 times a day but Knuth calls that kind of practice a 'waste of time' and claims 'nothing needs to be "mocked up."' He also states that methods to write software to take advantage of parallel programming hardware (like multi-core systems that we've discussed) are too difficult for him to tackle due to ever-changing hardware. He even goes so far as to vent about his unhappiness toward chipmakers for forcing us into the multicore realm. He pitches his idea of 'literate programming' which I must admit I've never heard of but find it intriguing. At the end, he even remarks on his adage that young people shouldn't do things just because they're trendy. Whether you love him or hate him, he sure has some interesting/flame-bait things to say."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
No threads? (Score:5, Funny)
How about "C++ threads considered harmful"? (Score:5, Insightful)
Re: (Score:3, 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 t
Re: (Score:3, Interesting)
The problem simply comes in that a program is not obligated to *use* synchronize, or any locking, when it accesses objects. Which means the code is totally unsuitable for integrating into a multithreaded program. And trying to backport thread-safety in is (currently) too difficult, as there are no tools to te
Re: (Score:3, Interesting)
I may have misunderstood (I'm not exactly an expert in threading), but I believe that Erlang handles this is a scarily elegant manner... once assigned, a variable can not be changed.
The = operator in Erlang should be looked at in the mathematical sense, so the following (pseudo) code would fail:
a = 2
a = 1 + 3
Because 1+3 != 2
(Disclaimer: I've briefly dabbled in Erlang, but anyth
Re:How about "C++ threads considered harmful"? (Score:4, Funny)
Parent
Not exactly a new sentiment (Score:5, Informative)
I use threads a fair amount, because they are there. But I kinda wish path expressions [wikipedia.org] 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.
I'm All For Getting Rid Of Threads, But... (Score:4, Informative)
Re: (Score:3)
Threads only seemed to get really popular with Windows. Unix programming has typically always been multi-process with some form of shared memory. I've heard (and this is unconfirmed hearsay) that CreateProcess() on Windows is so heavyweight that they pushed for a comprehensive threading model instead.
Re: (Score:3, 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 efficien
processes (Score:4, Interesting)
Parent
Re: (Score:3, Insightful)
Apache 1.x is not multi-threaded.
Re: (Score:3, Insightful)
Web server w/o processes OR threads... (Score:4, Informative)
Parent
I disagree with both this guy AND Dijkstra (Score:5, Interesting)
Use the best tool for the job, regardless of whether your CS professors demonized it or not.
That's not disagreeing with Dijkstra (Score:4, Insightful)
Unless you seriously think people should use gotos instead of loops and if/else statements, then you don't disagree with Dijkstra.
Parent
Not really news (Score:5, Insightful)
The author of this "article" (and I use the term loosely) doesn't really present such options. He hand waves a few work-in-progress solutions at the end, compares threads to GOTO statements, then asks the readers to fill in the (rather sizable) blanks.
Long story short, it's a good topic of discussion, but the comparison to Dijkstra's famous paper is just an advertising point. Nothing more, nothing less.
Hmm (Score:3, Interesting)
The problem is not threads per se, but the way they are generally used in programming languages like C and C++. Although const correctness is understood by some C++ programmers, they appear to be a minority if I judge by the code I regularly review. There is also memory management which is a much bigger issue in threaded C/C++ applications than in applications written in Java. The Java library provides good examples of immutable classes, most prominently the String class, that remove a number of problems often encountered with their mutable cousins like std::string. Unlike std::string, I don't have to remember to make it immutable by constifying it or wrapping it. The presence of immutable classes, and the more adequate coverage given them along with threading in Java textbooks means that I disagree with the articles' author who lumps Java threads in with pthreads as a bad thing. What we need is more coverage of threading issues and how to alleviate them in intermediate level C/C++ textbooks, because despite the fact that threading is not built into those languages or their standard libraries, concurrency has become too important to ignore once you go beyond the basics.
Right. Mod parent up. (Score:3, Interesting)
The problem is not threads per se, but the way they are generally used in programming languages like C and C++
Right. C and C++ provide zero help in dealing with the isolation issues of threading. The languages have no concept of parallelism (there's "volatile", but that's about it.) There were 1980s languages that did offer some help, such as Modula I/II/III, Ada, and Occam. Java has some minimal concurrency support, although it's not well thought out.
There's nothing wrong with multithreaded program
Re: (Score:3, Interesting)
"Threads" are not the problem. (Score:3, Interesting)
Writing a safe threaded application is not a difficult task, but it is a different task then writing a single-threaded app. And unfortunately CS programs, books, tutorials, etc, still train people in the single-thread mindset and yes the programs they produce end up being buggy.
And I'm not sure these 'high abstraction' languages are really the 'answer'. I have found that often in higher level solutions the results become even less predictable and tracing what is actually happening when becomes either extremely difficult, extremely inefficient, or just back to the single-thread mentality.
I think the OP talking about how one might be next writing a parrell app shows the real flaw here... the author is going from one mentality, entering another without really thinking it through, and then complaining when old methods don't work well. Take a programmer who STARTED in parrell space and you don't run into these problems.
chickens (Score:4, Funny)
A) to To other the side. get the
Fancy programming languages are NOT the solution. (Score:5, Interesting)
I'm tired of reading replies to this article that evangelize some fancy-schmancy high-level solution. I wonder if these advocates have ever tried writing production code in such an environment.
Let me give you a wonderful example of when theory simply doesn't meet reality.
Recently, I wrote a bunch of multi-threaded code for a next-generation asymmetric-multiprocessing game console that shall remain nameless. Its operating system has a wonderful complement of synchronization features. There's the usual mutex lock/unlock, and the usual condition signal/wait, but there are also event queues (queues of generic events that can be passed between threads running on different types of processors), lightweight mutexes/conditions, spinlocks, semaphores, reader/writer locks, and so on and so on. Truly a rich palette from which one can paint a wonderfully synchronized multi-threaded application! I then proceeded to try to rewrite a key section of our code in a very multi-threaded way.
The problem was, the first version of this code added NINETY milliseconds per frame to our main thread. A profile showed that nearly all of the extra time was spent in the operating system's synchronization features.
After much rewriting and much pain, I stopped using all of the operating system's synchronization features, and used processor-level atomic operations instead, and finally, the extra code accounted for only FOUR milliseconds per frame in our main thread (with the rest of the time successfully farmed out to separate threads).
I challenge anyone with a fancy-schmancy automatic concurrency solution to demonstrate that it doesn't have this problem.
Re:Slowaris caused threading (Score:4, Insightful)
Complete crap. Threads solve a number of programming problems much more elegantly than forked processes and sharing data through some IPC mechanisms. Anecdote time: a stock price system I worked on. The first generation used separate processes for a single writer and a large number of readers, with shared memory for interprocess communication. This was switched to a threaded implementation for the second generation, which was faster, even though it was using the old LinuxThreads implementation, and more easily maintained as the pthreads API is much richer than IPC ones.
Parent
Threads work fine (Score:3, Interesting)
I use them routinely on MS platforms. Background threads for write-behind mechanisms, for self-tuning caches, for animation. The sharing between threads is the more-precise problem, not threads itself. If one knows how to examine the context of a thread, one can see all shared pints and code accordingly. This is no different th