John Henry said to the captain, “A man ain’t nothin’ but a man. But before I let your steam drill beat me down, I’ll die with a hammer in my hand.”
—“The Ballad of John Henry,” American traditional
John Henry occupies a mighty place in American folklore (bit.ly/3HqIMd). Some folks say he’s just a tall tale, but others insist he’s based on a real man. John Henry “drove steel” in the late 1800s, pounding a sledgehammer onto a steel drill rod, boring holes into rock for blasting railroad tunnels. When a steam-powered drill threatened his job, John Henry challenged it to a duel—and won. “John Henry drove 16 feet and the steam drill only made nine,” the ballad says. But no matter which version of the song you hear, it always ends badly: “He worked so hard, he broke his poor heart, so he laid down his hammer and he died.”
What does such a quintessential hardware guy have to do with software, I hear you wondering. I had my own John Henry moment last week, teaching threads in my “Programming Microsoft .NET” class at Harvard Extension. I started my students with raw threads, then showed them the thread pool, then worked into the design problems of synchronization and thread affinity. I concluded with a brutal homework assignment that tempted them to use the thread pool but imposed requirements that didn’t allow it. (Student: “Platt, you’re a sadistic bastard.” Me: “Um, yeah, what’s your point?”)
The next week I showed them the Task Parallel Library (TPL), with its Parallel.For and Parallel.ForEach constructs. I then told them I myself didn’t trust it. It was too new. And it didn’t save me enough time and effort to compensate for the loss of control and transparency. Then I realized what I dinosaur I’d become.
Every advance in computing has generated a new abstraction layer. And with every higher level of abstraction, the programmers who strove mightily to master the lower level get angry. Now any idiot can do what they busted their asses to learn. Not fair!
For example, when those magnetic disk thingies first came out, programmers had to command the hardware directly—take head 3, move to track 19, wait for sector 247 to come around and then read it. Then some smart guy figured out how to hide the hardware behind a software abstraction layer that provided a logically contiguous series of bytes called a file.
“It’s way inefficient,” the fogies screamed. “You kids these days have no respect for resources. Think of all those sectors being wasted by, what do you call them, directories?”
“You bunch of old farts,” sneered the kids. “Do you still program with only ones and zeroes?”
When did I leap from upstart to fogey? I have no problem with the thread pool. I show students how it monitors the CPU usage of its threads, assigning more threads to the job when some of them block. But at least there I can see the threads, as opposed to the TPL, where they’re hidden.
I’ve always found there’s no substitute for knowing what’s going on under the hood. Abstractions always leak. Disks become fragmented, scattering files over inconvenient clusters that require wasteful movement of metal. The students who did the best in my MFC class years ago were the ones who heeded my advice to study Charles Petzold’s classic book on the Windows API. Whenever I fix a customer’s threading-related problem, it always—and I mean every single time, without exception—stems from a fundamental misunderstanding of what a thread is and does.
So go ahead, use the TPL Parallel.For and Parallel.ForEach. But if you use them as a crutch without understanding how they really work, it’s like using an inner tube to paddle out into the middle of Boston Harbor without knowing how to swim. You’ll be screaming for the Coast Guard, for guys like me, to come rescue you. Fortunately, we’re on the ball, because we know we have to be. A geek ain’t nothin’ but a geek. And before I let your TPL beat me down, I’ll die with a thread handle in my hand.
David S. Platt teaches programming .NET at Harvard University Extension School and at companies all over the world. He’s the author of 11 programming books, including “Why Software Sucks” (Addison-Wesley Professional, 2006) and “Introducing Microsoft .NET” (Microsoft Press, 2002). Microsoft named him a Software Legend in 2002. He wonders whether he should tape down two of his daughter’s fingers so she learns how to count in octal. You can contact him at rollthunder.com.
I agree with you Michael, but I'm not holding my breath until it happens. And I'd probably suggest that you don't either. Tx, Dave
I long for the time when I don't need to know how the abstraction works under the hood! I only want to need to understand the abstraction and the guarantees it gives (Service Orientation?). The owner/manufacturer of the abstraction should be responsible/liable for troubleshooting and fixing it when it doesn't provide the advertised guarantees.
"And before I let your TPL beat me down, I’ll die with a thread handle in my hand" And I will be by your side, Brother!
More MSDN Magazine Blog entries >
Browse All MSDN Magazines
Subscribe to MSDN Flash newsletter
Receive the MSDN Flash e-mail newsletter every other week, with news and information personalized to your interests and areas of focus.