Re:New Me (Score 1)

Your programming example would remove the need for mutexes, but that's about all. Spawning a thread, while faster than an entire process, has cost.

In your example, the context of the current thread would have to be duplicated (how does the compiler know what data operation() will use). They can't run from the same data - what if doSomeThing() modifies a field that operation() uses?

Java's FutureTask requires extra work, but it protects you from concurrent data modifications errors. (Or, it appears to. I'm not familiar with it...)

Your idea is good. We're eventually going to need a revolutionary way to parallelise computation on a larger scale (larger than instruction-level, anyway). But don't forget - at some point, all abstractions leak.

Even if we could split all function/method calls out to separate threads, there will still be waste. Just as instructions must wait for their inputs, so must your functions/methods. To get a well-optimised program, a software engineer will still be stuck with managing the critical path of execution.