Concurrent Development: Spotting the Wave

Over the years I’ve had the pleasure of working on several multithreaded applications but rarely have I been involved with the projects from the beginning. Usually I’ve been brought in because the teams couldn’t stabilize the systems. While this is a great ego boost and a chance to play the white knight – it’s a pain. I’ve had a lot of time to think about grid computing since I started at Digipede and very early I recognized the relationship between threads and grid objects. Both are tools that support concurrent software development and both have their place in solutions requiring high performance and scalability.

For those of you who haven’t been keeping up with the latest hardware trends. CPU clock speed has reached a major roadblock. The general computer buying public (this would be us) is not going to see new processors with faster chips until the hardware vendors figure out how to either reduce the generated heat or a how to more efficiently draw the heat away. To continue to bring us the new and faster computer chips that we’ve become accustomed to, the hardware vendors are adding processors to the core. Dual-core machines are already on the market and they are not restricted to servers. Those chips are going into desktops and laptops as well. And it has been predicted that the hardware vendors are not going to stop at two. I would take that bet.

In the past our applications would automatically reap the benefit of faster CPUs but that is not going to be the case with the multi-core machines. We, the software developers of the world, are now going to have to work to make our applications faster. This means that software developers are going to have to learn how to build software applications that take advantage of concurrency.

There are many differences between sequential and concurrent software development. Sequential software development boils down to the idea that there is only ever ONE part of your application running at any time. Even when it looks like there is more going on...say when you send a message, catch an event, run something asynchronously (without threads), etc... There is only one part of the application running and there can BE only one part running.

With concurrent software development, one or more parts of your application can be executed at the exact same time. I say can, because concurrent software applications that are run on a single processor machine are sort of a hybrid sequential/concurrent application. While parts of the application are capable of running at the same time (in parallel), there is only one processor and the single processor acts as a bottleneck. The operating system assumes responsibility for switching (time-slicing) between all the different threads and processes running on the computer. Barring the concurrent application on the single processor case; concurrent applications are designed to take advantage of multiple processors and of the operating system’s time-slicing capability resulting in the improvement of an application’s performance and scalability.

This is the beginning of a series of posts on concurrent software development; it is a journey that much of the software development community is going to have to take. I hope that the information that I share here will be make the transition from sequential to concurrent development easier.