Tim Jansen's blog


2005/01/05
Concurrency in Eek
Lamba the Ultimate links to a nice article about the upcoming performance challenges for CPUs. In the next few years, the single-thread performance of CPUs will slowly stop growing, and instead CPUs have to become faster by parallelization. I thought a lot about that topic in the summer, as I agree with the article's author that concurrency will extremely important for all system programming languages. However, my conclusion was that the langauge itself can not do much to make concurrency easier. There are many concepts like monitors, futures etc that try to make concurrency easier. Unfortunately they all fail, because none of them prevents the programmer from making stupid mistakes. Just forget to 'synchronize' or to put a lock around a variable access, and you have a bug that's hard to trigger but can cause fatal errors that are almost impossible to reproduce. My insight was that it is impossible to have a fool-proof way for two threads to use the same resource. So the only conclusion can be that this must be avoided at all costs, a resource should never be accessed directly by more than one thread. This lead me to a decent solution for many cases: split programs into many small modules that communicate using asynchronous messages. If more than one module need to work on a resource, this resource should be managed by a third module and the other modules need to communicate with the resource manager. Basically it is a service-oriented-architecture inside every application, with all SOA advantages like easy testing, buzzword-compatibility etc. I haven't found any reason why such a modularization needs to be integrated into the language though, so it's a pure framework feature (having EXML helps though). That does not mean that Eek won't have support for traditional multi-threading, it will have them at a level somewhat comparable to C#. And traditional multi-threading can make a lot of sense for performance reasons. Some selected modules/services benefit from supporting multi-threading internally, especially those that manage common resources. But that should be the exception, and the multi-threaded modules should be as small as possible.


 

This blog is my dumping ground for thoughts and ideas about Eek. Someday Eek will be a programming language and system, somewhat comparable to Java in scope. It is my attempt to bring sanity to the world of computing.
At least I hope so. Right now it is far from being finished and I can't guarantee that it ever will be. I am still working on the specification, but I won't release anything before I got my first prototype running. The world does not need more vapourware and unusable beta-software. All publicly available information about Eek is contained in this blog. You can find the latest summary here.
This page is powered by Blogger. Isn't yours? Creative Commons License
This work is licensed under a Creative Commons License.