Consequence of the end of 'The Free Performance Lunch'!
In the article titled 'The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software', Herb Sutter explains the importance of improving our skills on writing concurrent programs - ie if we need to gain performance gains form all the multi-core CPUs that are coming out lately.
In this light, I have collected a series of articles that discuss this matter in detail.
- An Introduction to Programming with C# Threads
- Threading in C#
- CLR Inside out: Using concurrency for scalability [MSDM Mag Sep 2006]
- What Every Dev Must Know About Multithreaded Apps [MSDN Mag Aug 2005]
- Advanced Techniques To Avoid And Detect Deadlocks In .NET Apps [MSDN Mag April 2006]
- WinForms UI Thread Invokes: An In-Depth Review of Invoke/BeginInvoke/InvokeRequred
Hope this helps.
technorati tags:Threading, Concurrency, CSharp










Comments
You might be interested in our approach to concurrency and coordination. The primary aim of our technology is to simplify the writing of scaleable, resilient, concurrent/distributed software solutions especially in the case of irregular concurrency. It would appear to us that the majority (if not all) of the other programming tools available seem to target ‘data parallel’ applications. We believe that we are the only provider of a solution that is effective for both regular and irregular concurrency.
We have not implemented a DSL in an ‘application related’ sense as we regard the area of concurrency as the domain we are interested in. It has been our intent to seperate the communications aspects of the solution from the algorithmic/processing aspects of the solution (similar to a co-ordination language). However, we extend the toolset to allow the developer to describe his/her solution using a graphical editor to create something similar to an electronic circuit; this will then be translated to the target language (currently C++). The developer will then be able to write the processing/algorithmic code without any knowledge of the threading/locking/synchronisation issues that writing ‘thread-aware’ code would entail.
We have a runtime which allows the solution to run on a number of OS’es without any changes, and, to run on any hardware topology without any changes (single process on one or more CPU’s (SMP), on shared memory multiprocessors (AMP), and/or heterogeneous networks of these platform types). This ‘hardware independent’ approach facilitates the development of the solution on, say, a desktop PC and allows the choice of hardware to deferred until closer to time of deployment. Hope this interests you from at least from a technological point of view.
Posted by: Stuart Smith | December 26, 2006 7:23 PM