Out and About – Aug 9th, Fresno, CA

This Wednesday, August 9th, I’ll be presenting at the Fresno .NET User Group. I’m going to be discussing concurrent software development, how threads work, and grid computing.

Year after year the hardware industry has been making our computers run faster and faster. But they have reached a plateau, we aren’t going to see an increase in clock speed for awhile. What we are going to see is more onboard cache and cpus. No more "free lunch" for us software engineers. Now we have to ensure that the performance improvements come from our software. And that means concurrent software development.

I agree with Herb Sutter’s assessment that the software industry is ready for another paradigm shift as significant as the OO shift. And like the OO shift it’s going to hurt and some of us aren’t going to be able to make the change. I’ve been building multithreaded applications since 1993 and I’ve made a few observations. First of all, multithreaded development is very different from sequential development. Second, multithreaded development is not intuitive, most people use threads and have no idea what is really going on. That is why the threading part of my presentation is going to talk about what is really happening in a threaded application.

Here are some links that will be useful to read before the presentation:

Multi-core chips provide power but make development tough

"Tom Halfhill, an analyst for In-Stat's "Microprocessor Report" in San Jose, says some software developers are "tearing their hair out" over the new CMP systems. "Rewriting the software for multi-threading is a lot of work, and it introduces new bugs, new complexities, and the software gets bigger, so there is some resistance to it.""

"But the CMP train has left the station, whether software developers like it or not. Intel says 85 percent of its server processors and 70 percent of its PC processors will be dual-core by year's end."

The Core Issue

"The biggest learning curve will be for programming teams that target consumer and business desktops. Until now, nearly all such platforms used one single-core processor. That meant that thread management was handled in software, not in hardware. While multithreaded applications would be slightly more efficient in a multitasking environment, the benefits of threaded designs were rarely emphasized by architects. Deadlocks and race conditions could be managed by the operating system. In short, programmers didn’t have to think about it. "

The Race is On to Debug Dual-Core Deadlocks

"Deadlocks...Race conditions....Detecting either error is difficult because collisions don’t always occur, so pinpointing the problem is a matter of timing, said Ken Cowan"

"Designing for concurrency is about getting a clear focus on how to decompose a problem, added Intel’s Reinders. "You are asking: ‘How do I break this program up?""

Concurrent software development requires a more structured approach to design, development, and testing. Those engineers and testers who grok the concurrent model are going to be worth a lot of money and are going to be very employable until the ability to use concurrent methodologies is as common as the ability to use OO methodologies. Wednesday’s presentation should get you heading in the right direction.

Update: Yes slides will be available. I will need to talk to Gustavo to find out the best distribution method. It may be that ya'll will have to send me an email and I will send them off to you. I didn't see a download section on the website.