The future of concurrent programming

[James Dennett]

Regan Heath wrote:
> Daniel Keep Wrote:
>> freeagle wrote:
>>> Why do people think there is a need for another language/paradigm to
>>> solve concurrent problem? OSes deal with parallelism for decades,
>>> without special purpose languages. Just plain C, C++. Just check Task
>>> manager in windows and you'll notice there's about 100+ threads running.
>>> If microsoft can manage it with current languages, why we cant?
>>>
>>> freeagle
>> We can; it's just hard as hell and thoroughly unenjoyable.  Like I said
>> before: I can and have written multithreaded code, but it's so utterly
>> painful that I avoid it wherever possible.
> 
> I must be strange then because after 5+ years of multithreaded
> programming it's the sort I prefer to do.  Each to their own I
> guess.
> 
> I think perhaps it's something that can be learnt, but it
> takes a bit of time, similar in fact to learning to program
> in the first place.  I enjoy the challenge of it and I think
> once you understand the fundamental problems/rules/practices
> with multithreaded development it becomes almost easy, almost.

It seems that most people, on finding a deep understanding of
multi-threaded programming and concurrent design, find that it
is hugely more complicated to do well than designs which do
not need concurrency, in most situations.  They also find that
making effective use of a large number of processors is a
very difficult problem (except in the case of so-called
"embarrassingly parallel" tasks).  Many problems split into
a number of naturally parallelizable parts, and exploiting
that isn't very hard, but efficiency and true scalability is
a lot more work that just creating some threads and using
message passing and/or synchronization for shared state.

I've seen a lot of code written by a lot of professionals,
and the multi-threaded code generally has close to an order
of magnitude more defects than the single-threaded code.
You may actually be proficient, but sadly most of them
also think that they are proficient.  The better ones tend
to be very wary of concurrency -- not that they avoid it,
but they take great care when working with parallelism.

-- James