|
The Transition to Concurrency
 Introduction
Concurrency is going to be crucial in the near future. The talk has been going for years, but now that Intel and AMD are actually starting to move that way too, you know there is something about it. A tremendous amount of articles such as this have been written on the subject lately, so I am not going to reiterate the evidence. Instead, I want to talk about what we are going to do - right now.
If you're a C++ programmer, you have surely been exposed to semaphore-based concurrency. Mutices and other kinds of locks are currently the most popular way of doing concurrency, despite the fact that it is one of the most difficult to use.
Furthermore, people often use them in a way that yields poor performance. Although you should not discard them completely, using semaphores should definitely not be the first and only option you consider when writing concurrent code.
Erlang and Friends
There are many ways to approach concurrency. Choosing an apt programming language is one. Erlang is a functional programming language designed specifically for concurrent programming.
Functional languages in general have the capability to excel in the concurrency area. A functional language such as OCaml is already famous for its optimizing compiler which makes it a language that is not just capable of achieving great performance - it actually does. This should make OCaml an obvious choice for concurrent programming.
But Why Change Language?
If you are interested in performance, chances are you are writing server code, embedded code or maybe game code like I am. And if that is the case, chances are that you are writing C or C++, and you are probably skeptical about other languages. In the end, they're all Turing-complete, right? So what could any language offer that you can't simulate?
Well you're right of course - there is nothing you can't achieve by simulating it. You can use or come up with design patterns that help you with everything. After all, design patterns are often described as language features that haven't (yet) been implemented. You can write object oriented code in C, simulating inheritance and virtual methods and everything but at the cost of increased complexity. Simulating functional programming in C is a pain. With C++ it is a slightly more bearable pain, but a pain nevertheless.
But even if you accept the fact that there may be better suited languages for the task, you may not have that option. No programmer is an island - you have to work with other programmers, you probably have management to respond to and changing languages is not a trivial decision. Plus, for many platforms, the C++ compiler is the only thing available.
At Flux Studios, we have been using C# for some scripting, assuming that Microsoft would provide support for the Xbox. Though they probably will, it seems unlikely that C++/CLI will be supported in the near future, which pretty much breaks the deal for C#.
(If your target platform is the VM of Java or .NET however, you could experiment with one of these hybrid languages: Scala, Nemerle or F#. They look quite interesting yet not too alien to Java or C# programmers).
Initiatives such an OpenMP may actually bring C++ somewhat up to the challenge, but even with that in your toolbox, you are best off understanding some of these paradigms that are well suited for concurrency.
|
|
|
|
|
