Will the need to program multi-core systems increase our awareness of existing approaches to concurrent programming? Will concurrency become an extension to the existing popular programming languages, bring about adoption of new or will become a transparent capability in the operating system? Here is an interesting look at Erlang, a language designed for concurrency and distribution in mind.
Our free pass will expire soon, though. Brian Goetz, one of the industry’s top concurrency experts, has written about high-performance Java, including concurrency, for more than a half a decade now. Brian believes that you’re likely to see a significant increase in concurrency problems, thanks to the laws of physics, subsequent demands on programmers, and shortcomings in the current model.
Moore’s Law predicts that the number of transistors on a chip doubles every two years. Semiconductor manufacturers are about to hit some physical limits that will impact their ability to double the transistors on a single wafer, so you’ll see matrices of processors. That change will force more concurrent programming, bringing more developers kicking and screaming into distributed programming.
I am no expert in concurrency, but keenly aware of its importance as we keep getting multi-core systems. Intel is promising 80 cores in a single chip within the next 5 years and investing a lot of money in training developers to program multi-cores. We need languages and tools to build, test and optimize the next generation applications.
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.