Over the years software development has relied on increasing processor clock speeds to achieve better performance. For better or worse though the trend has changed to adding more processing cores. Generally speaking, software development hasn’t adjusted to account for this transition. As a result many applications aren’t taking full advantage of the underlying platform and therefore they’re not performing as well as they could. In order to take advantage of multi-core and multi-processor systems though we need to change the way we write code to include parallelization.
Historically, parallel programming has been viewed as the realm of highly specialized software where only experts dared to tread. Parallel programming aims to improve performance by executing multiple operations simultaneously. The .NET framework has always supported some level of parallel programming. It has included threads and locks all the way back to the early days of the framework. The problem with threads and locks though is that using them correctly is difficult and error prone. Where do I need locks? Can I lock on this? Should I use lock, ReaderWriterLock, or ReaderWriterLockSlim? How do I return a result from another thread? What’s the signature for the ThreadStart delegate passed to the Thread constructor? These questions haven’t even started to touch on pooling, deadlocks, exception handling, cancellations, or a multitude of other considerations. .NET 4 doesn’t eliminate these classes but builds upon them.
(more…)
Like this:
Like Loading...