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.