http://www.perlmonks.org?node_id=580004

The future is threaded.

At the commodity hardware level, this is already the case thanks to Intel Hyperthreading, Intel, AMD (and others) dual core processors. AMP, SMP & NUMA. Dual, quad & 8-way motherboards. In the future it will be more so. Eg. The Cell processor. Quad-core technology from Intel and AMD coming in 2007.

At the software level, very little existing software makes use of threading. There are several reasons for this:

  1. Software needs to be written from the ground up with threading in mind in order to properly benefit from it.
  2. Retro-fitting threading to existing applications is rarely effective because threading exacerbates the effect of every bad programming practice.
    • Re-entrancy issues can not be glossed over. Whether in the application code, language runtime or OS.
    • Global data-structures become even more vulnerable.
    • Tight coupled code causes low granularity. Low granularity can make threading expensive.
    • Memory management becomes paramount.
      • Stop the world GC will have a disastrous effect upon performance.
      • Monolithic heap management will suck the life out of efficiency.
  3. Existing code that can benefit from threading, often uses event driven and/or state machine techniques to approximate those benefits, but code designed to utilise those techniques is usually structured such that it does not lend itself to conversion to threading.
  4. Existing code that already achieves parallelism through forking, that could also benefit from shared state, is often difficult to adapt to threading due to the assumptions that can be safely made when using forking that no longer hold true with threading.

Redeveloping existing, successful applications that could benefit from threading is often slow to happen. Again, for a variety of reasons:

  1. Mid-life, ground-up, redesign of an existing application is always a major undertaking, even where there are clear benefits to doing so.
  2. In many environments threading is seen as hard.
  3. In many environments, there is a lack of both understanding and the skills required to implement threading well.

Even when developing new applications, that could obviously benefit from threading, it is overlooked, ignored or explicitly ruled out. Again there are a variety reasons why this happens, most of which are already covered above.

Much of the resistance/reluctance to utilise threading can be attributed to a single factor--there are few if any good tools available.

And like any other type of existing application, adaption to threading is difficult, resisted ,expensive and risky. Redesign from the ground up with threading in mind, implies throwing away thousands or millions of development hours in thoroughly tried and tested tools and libraries.

Could that possibly be worth the trouble?

What if an existing, popular, powerful and flexible language was already being redesigned from the ground up.

If that language was already looking to support simple syntax and intuitive semantics for Distributed Operations?

if( any( @list ) == constant ) ... @list1 >> += << @list2

And those DistOps inherently lent themselves to being run concurrently on multiple hyperthreads/cores/CPUs?

What if the entire tool-chain to support that new language was also already being redesigned from the ground up?

Doesn't it make sense to write those tools with threading not just "in mind", but as a high priority?

Will those tools be all they could be, if their architects "Don't do threads"? If the implementors "do not see the need for threads"?

Indeed, does it bode well for the future of those tools if the implementors do not use the languages that those tools are to support, And don't have the slightest feel for what will drive the needs and uses of those languages in the future?

Does the

inspire you with confidence?

What about userspace threading? Many languages provide this and many programmers find it's determinism and light weight lends itself to many things that they want to do. It's not a replacement for kernel threads, but if threads != interpreter, then providing primitives to allow cooperative, user threading to run within preemptive kernel threading becomes not just possible but almost trivial. Whether this is provided at the VM level or the language level. Trying to hack user space threading into a language when thread == interpeter becomes a completely different ballgame.


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.