Mike Schilling wrote:
Arved Sandstrom wrote:
I don't doubt that 80-90 percent of the people who currently work as
programmers couldn't competently write reliable concurrent code, but
then OTOH they can't write reliable code period, so it's really got
nothing to do with concurrency. A software developer who can write
high-quality code can write high-quality concurrent code, and not have
to agonize over it either.
Concurrency leads to difficult and subtle problems, particualry as
code evolves over the years. That makes it more difficult to write
correctly and more fragile than code which does not need to be
concurrent.
I don't believe for a second that concurrency _inherently_ leads to
difficult and subtle problems. I do believe that not understanding
concurrent programming leads to difficult and subtle problems.
I'll agree that you probably don't want junior programmers writing your
multi-threaded code. But too many people make it sound like writing
concurrent code is insanely difficult. Well, no, it's not. The execution
of concurrent code is not a roll of the dice; it's as well-behaved as
any other code if you knew what you were doing when you wrote it.
Is "Java Concurrency In Practice" a really hard read? No. Is there such
a huge amount of material in there that it's difficult to learn what you
really need to know? No. Similarly for .NET - is "Concurrent Programming
on Windows" (by Joe Duffy) such a hard read? No.
I still believe that programmers who are finding that writing concurrent
code is really, really hard probably find most other kinds of coding
pretty difficult too. In my experience most programmers who are having
problems reasoning about what their code may or may not do in a
concurrent situation don't fully understand what their code is doing in
a single-threaded environment, nor do they adequately understand the
concurrency capabilities of their language.