The more general problem: Blending of concerns

Threaded design patterns have evolved over decades as special cases of a more general problem; “Blending of problem specific concerns with runtime specific concerns”.
While writing code, the programmer is concerned with a mix of different issues. Some of them are specific to the problem that he is trying to reduce to computer code, while others are related to the runtime where the code is going to execute. One example being the threads themselves which are totally a runtime specific issue.
While recent attempts like Java and .NET have given a quantum leap forward in separating such concerns, we argue that they have taken a slightly wrong direction.
While they have separated managed code from unmanaged code and explicit memory management from implicit management and introduced common language runtimes to abstract out the code from its execution environment, they have not addressed the core issues correctly; that is of the “separation of problem specific concerns from runtime specific concerns”.
One problem specific concern is the inherent parallelism available in it. To exploit this parallelism, the programmer still needs to concern himself with run time formalisms. The programmer is  dealing with the run-time via system calls related to threads and their synchronization, spawning new threads, terminating them on the fly, managing thread pools, creating and acquiring locks and mutexes, dealing with deadlocks and their avoidance and prevention, waiting on conditions and semaphores  to name a few .
The programmer doesn’t know at program time whether the code is going to run on a single core, single processor system or would be running on a multi-core, multi-processor system. And what about scaling the application to a cluster of servers or even out to the cloud?
Take e.g. a problem that programmer faces when passing a simple message. If it is passed by reference, it can only be run by another process running on the same shared memory. If it passes by copy, it can be run on a process running in a separate memory context but then it is an unnecessary burden on a system with shared memory. There is no way a programmer can handle this at coding time for all deployment scenarios.
In theory once the program has been reduced to correct executable code, the code should be able to run on all deployment scenarios without having to go back to the programmer to adjust his code as per new runtime environment. Easier said than done.
We argue that the correct separation is between “problem specific concerns and runtime specific concerns”. The job of the programmer is not to find “how” to exploit the parallelism. His job is only to mention “what” the parallelism is. To deal with runtime, we need to introduce a ‘middleware’ and i t is the job of the ‘middleware’ to find out “how” to use the parallelism on the given runtime. The programmer does this by making the ‘middleware’ aware of the inherent parallelism in the problem and for this, specific formalisms need to be provided. Once this awareness exists, it is the job of the middleware to exploit the runtime environment provided to it and ‘map’ problem specific abstractions correctly to runtime.
When and if this is done correctly, the same code should run as good on a single computer as it runs on a cloud based distributed structure, obviously exploiting all the powers of the cloud.