[concurrency-interest] Economist article

Gregg Wonderly 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 
worry about.

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 
multi-core/hyper-threaded processors.

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,
> 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
>> occurrence.
>> 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
> uniprocessors.
> 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).
> David
>> 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
>>> David
>>>      -----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.
>>>          --tim
>>>          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."
>> <http://www.economist.com/node/18750706?frsc=dg%7Ca><http://www.ec
> onomist.com/node/18750706?frsc=dg%7Ca>
>>              http://www.economist.com/node/18750706?frsc=dg%7Ca
>>              The article mentions Scala but not java.util.concurrent.
>>              To me, this problem still seems more "derivative" of the
> technology
>>              and less driven by consumer demand, and I'm disappointed that
> The
>>              Economist could not find a more compelling statement.
>>              Is this really a case of: To the man with a multi-headed
> hammer,
>>              every problem looks like a multi-headed nail?
>>              Maybe my mobile-shaded perspective will change now that
> multicores
>>              are shipping on handsets...
>>              Joe
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list