Evolving concurrency, like memory management did

As processors become faster and multiprocessor systems become cheaper, the need to take advantage of multithreading in order to achieve full hardware resource utilization only increases the importance of being able to incorporate concurrency in a wide variety of application categories.

In this article we are evaluting a new approach to the concurrency.
In the last five years computers are becoming even more parallel.
Intel is pushing multi-core achiteture also on commodity personal computers.
Neverless the computing power is ofter not well used: one again, hardware is a step head of our day-by-day software development.
Remember when the 80286 came into light.
The 286 was able to provide a multi-programming architecture but without memory management protection.
We had to wait 386 hardware to see software working on preemptive multi-tasking, because software cannot cope with unprotected memory. In one word, it costs too much to develop a operating system without the new features the 80386 bring to us.
What about concurrent programming? Can we look similarities in the  concurrency field?

The evolution of IT was always tight linked with economy factors, and contingent needs. Best IT evolution has been originated from Customer demands, focused on optimizing economic processes.

For instance, in the old days, mainframe has only one main memory (RAM); then hard disks appeared, for storing big amount of data.

So a modern PC has a small amount of RAM, plenty of Hard disk space and network storage.
Operating System evolved  for managing CPU time and application memory. The application has little knowledge of memory management.

In a similar way, database are a way of managing huge amount of information, in the same abstraction like Service Oriented Application can be seen like an abstraction of web communication.

Also Internet can be seen as an information extension: the Internet is the biggest online archive we have.

Can we trace a similar approach for concurrent programming?

In an ideal world, we should have an entity which manage inter-process communication, deciding how to spread the load of a multi-thread program.

Erlang [2] approach is very similar to a operating system view. Erlang variables are immutable (like in lisp). The system is composed of light processes, your code declares. The language infrastructure then orchestrate the processes, mapping them to the available resources (physical processors).
It is also easy to map the process on multiple nodes (hosts), even if this it is not automatic.

There is a long tradition of Transaction Monitor operating system, which have little lucky sitting behind the  Java Enterprise Specification (J2EE) in the form of Enterprise Java Beans.

J2EE Enterprise Java beans results difficult to manage, and had little success on some areas. Worst, the cost associated with J2EE application servers was too high in respect of the benefits.

So transaction monitors are kept out of our discussion.

Kilim[4] is a very aggressive solution, looking the Actors[8] specification.

Also Scala[7] offers a similar approach.

Open Troughts

What do you think? Do you have experience about super-efficient language displacing tasks easily?

Give me your feedback!…and keep in touch for the next series of articles

References

  1. Crossing borders: Concurrent programming with Erlang
  2. Erlang documentation
  3. Java Implementation Erlang-like: JetLang, which is a library for “high performance java threading”.
  4. Kilim is a message-passing framework for Java that “provides ultra-lightweight threads and facilities for fast, safe, zero-copy messaging between these threads”.
    It seems to use a implicit byte code manipulator, which sounds a bit dangerous so we avoided it.
  5. Python Proxy recipe
  6. Python Candygram
  7. Scala Actors
  8. Actors: general terminology from Wikipedia