Mike Schilling wrote:
Arved Sandstrom wrote:
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.
Then your intuition disagrees with what I've observed over decades. I'm
afraid I won't defer to it.
Nobody is asking you to defer to anyone else's observations. I'm
simply stating that I don't believe that concurrent programming is
very difficult. If you think that concurrent programming is
inherently very difficult then that's your prerogative.
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.
Multithreaded code beahves different every time you run it. The
same inputs can lead toi different output, which is bad enough, but
in the real world you oten find quite different inputs.
Wait, hold on - let's be clear on what you just said. "Same inputs can
lead to different output". And "multithreaded code behaves different
every time you run it".
That, translated, means that the code isn't thread-safe.
Not at all. Thread-safe code is code that's always correct even though it
It has problems like thread
starvation that non-concurrent code does not have. It's inherently
less portable than other Java code, because different platforms have
different threading models; in particular, this can severely affect
efficiency.
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.
And? The JLS isn't particularly a hard read. That doesn't mean
that Java programming is simple, regardless of the problem you're
trying to solve.
Are you finding it difficult, though? Leaving aside the specific
real-world problems, are you finding the implementations in Java to be
really hard work? I doubt that you are.
In the same vein, do you really find concurrent programming to be
_very_ difficult, or simply deserving of some extra care and
attention just like you'd apply to the efficient and correct
implementation of a complex algorithm? I find it much more like the
latter, rather than that multi-threading suddenly makes everything
really, really hard.
subtle bugs and more fragile than single-threaded code.