[concurrency-interest] Economist article
gregg at cytetech.com
Tue Jun 14 22:00:06 EDT 2011
David, I was lumping hyper-threaded in with multi-core, sorry for not being
clear about that. Yes, I agree that there were some choices of multi-processor
support on desktops, but only in large software shops was that happening. Those
shops were producing the old "server systems" and "realtime/high performance"
software systems where there wasn't "Java everywhere". There was C and there
was P-Threads and lots of stuff like that. But, it was really not accessible to
the common developer because there was all the "required documentation" and very
painful C programming and "command line tools" and "that beasty Unix stuff" to
I'm all too aware of many things that did happen in large corporations with very
narrow, vertical software systems. Java made threading dead easy to "do", but
not so simple to get "right" because the constructs were as low level as was
possible. The single threaded, linear software programming taught in many
places only hinted at the possibility of having to deal with such issues,
because, it was not common.
It may be that many people on this list feel like there is old hat. I've been
dealing with lots of problems in Java software systems, over the years, related
to people not understanding concurrency. It's a large problem related to
relative experience and education for sure. Developers had no choice in
whether the hardware changed or not. They had limited tools to test with,
because it required that the hardware exist and be accessible. It existed, but
for a lot of people, it was not accessible.
The most telling evidence of the problem, for me, is the continued problems that
people have using the hardware, no matter what software system you want to
consider. Everywhere I look, there are people having to deal with concurrency
issues in software that were not there before the presence of wide spread
Sure, new software has the benefit of being designed with "the knowledge"
already present. However, the skills and tools available still don't really
match up to what developers need.
I'd really like to see people involved in developing Data Flow based solutions
for studying code paths and finding multi-threaded access. We should, by now,
for example have required annotations for classes that are multi-threaded, as
well as method annotations that define threading characteristics. There should
be tools that can analyze codebases with such things and say, for sure, that
there are multi-threaded code paths, volatile access needs and everything that
can go wrong, spelled out.
It's just nuts to not have such tools! Why are we content to sit around and say
that we can't possibly analyze code paths and that you can not test to prove
that software is concurrency safe? With data flow analysis, every path in
software is reachable. Are they all necessary to traverse, no, but we have the
ability to use software tools to make the job easier. It just needs to be
tackled aggressively with the right focus.
This page, http://laser.cs.umass.edu/staticanalysis/ has an illustration that
analysis can generate results. There are, of course things starting to happen.
The illustrative properties of this article, for me, are real world statements
of what is actually the issue, not what some people believe might be a way to
look at the cause of problems which developers are experiencing regarding
The problems are real, and are here and now. Our current software systems are
very deficient in helping developers to write correct concurrent software. We
think of concurrency problems as "indications of stupidity, or ignorance"
instead of as "hard problems" which require tools. In a sense, currency
concurrency constructs and tools are almost like assembly programming with hand
assembly. We know all the details and demand that developers craft all the
intricacies each and every time, and not make mistakes and not have tools, such
as assemblers. The fork and join framework in Java is like an assembler. It
makes all the right instruction codes appear in the output, but still doesn't
help to make sure that the ordering and machine (the application logic)
dependent issues are taken care of.
On 6/14/2011 5:30 PM, David Holmes wrote:
> Gregg Wonderly writes:
>> On 6/14/2011 5:02 PM, David Holmes wrote:
>>> And it's always written as-if we'd never had multi-processors
>>> before we had multi-core.
>> That's a fair viewpoint, but multi-processor machines were a rare
>> Only when multi-core hit the desktop was there plenty of places
>> to "witness" the
>> problems of single path software designs on multi-path processor systems.
> Maybe it's an issue of terminology but dual-processor desktops were not that
> rare 10 years ago (dual proc laptops maybe). Further, hyper-threaded systems
> were far from rare and still exposed race conditions masked on true
> Multi-core didn't come out of thin air from left field and take us by
> surprise - well not some of "us" anyway.
> I find all of these articles completely disengenous because they are written
> as if MP/MT/MC is something brand new that has hit us unaware and that is
> just a load of bulldust. Certainly the applicability of MP/MT/MC is
> spreading and the number of cores is increasing, but the basic principles of
> concurrent programming apply on 2 cores as well as 200 - it is scalability
> and performance that suffers as the number of cores increases (with shared
> memory multi-threading anyway).
>> In so many ways, multi-core was "sprung" on software developers and their
>> development tool sets with little help and support for developers
>> to understand
>> and adequately "prove" software systems to be safe and operate as
>> designed, really!
>> Gregg Wonderly
>>> -----Original Message-----
>>> *From:* concurrency-interest-bounces at cs.oswego.edu
>>> [mailto:concurrency-interest-bounces at cs.oswego.edu]*On
>> Behalf Of *Joe Bowbeer
>>> *Sent:* Wednesday, 15 June 2011 4:49 AM
>>> *To:* concurrency-interest
>>> *Subject:* Re: [concurrency-interest] Economist article
>>> The problem is always stated as "we have these multicores
>> so now we have to
>>> figure out how to use them".
>>> On Tue, Jun 14, 2011 at 11:36 AM, Tim Peierls wrote:
>>> I didn't pick up the everything-is-a-nail vibe. The
>> article just points
>>> out that languages, programmers, and educators are
>> unexpectedly playing
>>> catch-up because of the proliferation of multicores on
>> the desktop,
>>> something readers of the Economist probably wouldn't
>> know about without
>>> being in the biz.
>>> On Tue, Jun 14, 2011 at 12:53 PM, Joe Bowbeer wrote:
>>> "Parallel programming, once an obscure niche, is
>> the focus of
>>> increasing interest as multicore chips proliferate
>> in ordinary PCs."
>> The article mentions Scala but not java.util.concurrent.
>> To me, this problem still seems more "derivative" of the
>> and less driven by consumer demand, and I'm disappointed that
>> Economist could not find a more compelling statement.
>> Is this really a case of: To the man with a multi-headed
>> every problem looks like a multi-headed nail?
>> Maybe my mobile-shaded perspective will change now that
>> are shipping on handsets...
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
More information about the Concurrency-interest