Thursday, August 24, 2006
Concurrency on the web
Lately, I've been noticing that more and more people are beginning to discuss concurrency and how it relates to the new multi core CPU's that are being released.
Kim Greenlee's blog post
Herb Sutter's article on concurrency
Musings about concurrency and manycore CPUs
Larry O'Brien
Most of the discussions center on how to design software to take advantage of multiple cores, and how to come up with an easy way to get developers interested in concurrency. Designing software to take advantage of multiple CPUs is familiar to most systems software engineers (operating systems, web servers, database servers, search engines), but most business applications are still designed to take advantage of a single CPU. Most business application developers are not familiar with concepts such as threading, synchronization, shared memory/data, deadlocks, etc. because the software that they build usually has the requirment that it perform one task at a time, in serial because there was never a requirement to run tasks in parallel. Even if there was a requirement to run tasks in parallel, it would probably be easier to install the system on a new machine and load balance both systems, since the cost of a new machine is less than the time/effort cost for the developer to redesign the system as a concurrent system.
From the business application developer standpoint there are two questions they will ask about concurrency: How can I split my application into different business processes that can run independently of one another? what's a thread? why would I use it? what's a lock? what's deadlock? All of these questions will need to get answered if the developer wants to take advantage of all of the computing power available to them. The questions around threads, locks, synchronization, etc. are easy to find answers to, there are lots of books/websites on the topic. The more difficult questions to answer are about how to divide applications into business processes that can run in parallel. Since every business application is different, there probably is no one right answer to this question, but I do feel that it is useful for developers to become familiar with how system engineers solve problems by programming for concurrency. Basically, I believe that we will start to see more and more design patterns that are used to solve concurrency problems. Martin Fowler's book: Patterns of Enterprise Application Architecture has a section on concurrency, and the book Data Access Patterns also has a section on concurrency, so these are two good places to start. For learning about multithreading, the book .NET Multithreading is a good one. There are a few frameworks that may make developing concurrent applications easier on the .NET platform:
Although not .NET-only, the framework OpenMP is another choice.
Kim Greenlee's blog post
Herb Sutter's article on concurrency
Musings about concurrency and manycore CPUs
Larry O'Brien
Most of the discussions center on how to design software to take advantage of multiple cores, and how to come up with an easy way to get developers interested in concurrency. Designing software to take advantage of multiple CPUs is familiar to most systems software engineers (operating systems, web servers, database servers, search engines), but most business applications are still designed to take advantage of a single CPU. Most business application developers are not familiar with concepts such as threading, synchronization, shared memory/data, deadlocks, etc. because the software that they build usually has the requirment that it perform one task at a time, in serial because there was never a requirement to run tasks in parallel. Even if there was a requirement to run tasks in parallel, it would probably be easier to install the system on a new machine and load balance both systems, since the cost of a new machine is less than the time/effort cost for the developer to redesign the system as a concurrent system.
From the business application developer standpoint there are two questions they will ask about concurrency: How can I split my application into different business processes that can run independently of one another? what's a thread? why would I use it? what's a lock? what's deadlock? All of these questions will need to get answered if the developer wants to take advantage of all of the computing power available to them. The questions around threads, locks, synchronization, etc. are easy to find answers to, there are lots of books/websites on the topic. The more difficult questions to answer are about how to divide applications into business processes that can run in parallel. Since every business application is different, there probably is no one right answer to this question, but I do feel that it is useful for developers to become familiar with how system engineers solve problems by programming for concurrency. Basically, I believe that we will start to see more and more design patterns that are used to solve concurrency problems. Martin Fowler's book: Patterns of Enterprise Application Architecture has a section on concurrency, and the book Data Access Patterns also has a section on concurrency, so these are two good places to start. For learning about multithreading, the book .NET Multithreading is a good one. There are a few frameworks that may make developing concurrent applications easier on the .NET platform:
Although not .NET-only, the framework OpenMP is another choice.
