Appistry is one way of doing it

Appistry 3.5

allows Java and .NET applications to scale out across a number of servers while running as though it were one application on one server. The Fabric makes the application think it's running on one computer, and the developer writes applications as though it will run on a single computer. But in execution, the application could be distributed over 100 or more computers.

So we seem to have at least 4 approaches:

1. The conventional multithreading where the programmer writes all the controls for the threads and how they share and don't share data, in the hope of optimizing resources (e.g., threads, memory, communication).
2. The future multithreading yet to be usable, where the programmer does not have to write all the controls for the threads and how they share and don't share data, yet resources are still optimized.
3. The Google Grid technique called MapReduce.
   
4. The Appistry Grid technique where the programmer writes single-threaded logic and the underlying system takes care of managing the available resources (threads and memory).

The Appistry approach seems to pose difficulties for applications that require multiple threads to share data. It allows applications to launch multiple threads but probably does not offer more help for controling their interactions than what the language already offers. This remains to be verified. If it is the case, then for scaling, the programmer has to make difficult non-obvious choices between the single-thread auto-scaling by Fabric versus the conventional multithreading approach. I would think that if you have Fabric then you minimize your use of multithreading.

Gosling Agrees: The next big thing is multithreading

Dr James Gosling on c|net news.com, March 19, 2007: The next big innovation is multithreading.

What do you think will be the next big tech innovation that will affect enterprise IT?
Gosling: There's a lot of stuff going on around multithreading--for example, the way that Moore's Law is shifting from clock rate to number of cores, which means people have to be increasingly conscious of what it means to build multithreaded applications.

Erlang is top contender for distributed app today

The book on Erlang, by the creator of Erlang, Joe Armstrong.

Joe designed and implemented the first version of Erlang in 1986 and he currently works for Ericsson AB where Erlang is used to build highly-fault tolerant switching systems.

The above link has links to 2 large size pdf extracts from the book. One is http://media.pragprog.com/titles/jaerlang/Concurrent.pdf

The web site on the open source version: http://www.erlang.org/

Here's a 2007.03.03 blog by Tim O'Reilly on Erlang and other concurrency issues.

Tim mentions that some have found Erlang to be too "old".

TODO learn Erlang

Erlang is called "a pure message passing language". Erlang processes do not share memory. It is excellent for distributed apps but can it be considered a standard multithreaded language? I do not yet know if Erlang has threads where memory is shared.

I recommend that we distinguish standard multithreaded languages where threads share memory from those where threads do not share memory.