[concurrency-interest] Economist article

Gregg Wonderly gergg at cox.net
Tue Jun 14 16:32:26 EDT 2011


On 6/14/2011 1:48 PM, Joe Bowbeer wrote:
> The problem is always stated as "we have these multicores so now we have to
> figure out how to use them".

This is my view point as well.  Even though Java had locking available to 
address the issue of multi-threading through multi-processor machines, the 
average java programmer had no access to such machines except in places like 
JavaEE environments, where there as limited access to "threading".

When the first multi-core machine experience landed on my desktop, it was 
amazing how many problems I found in software which had worked flawlessly 
before, simply because of visiblility, optmization (the rediculous volatile 
optimization to while(true)) as well as concurrent access on unlocked structures.

There were not "path" analysis tools (and I still don't see them today) which 
can exhaustively document the "single threaded" entry points into code so that 
you can say, hey, that's not used by a single thread, and fix the problems.

Sure, the chip manufactures think that it is great to add more cores to make 
"processors" "more performant", but developers can get no benefits from that 
simple step without a steep learning curve in something that many seemed to have 
never be trained in.

My view point is that more than 80% of the people that exist today as "software 
developers" are just "microsoft office plugin developers" or "self trained" "web 
developers" who have a very small set of skills in advanced computing 
engineering.  The end result, is that you can count on concurrency bugs, 
circular wait, and (with Java) visibility bugs in almost every application in 
the public computing infrastructure.

The other 20% are people working in real-time or classified/high performance 
projects which only hire people with demonstrated skill sets.

The other 80% just need a piece of paper with a degree name on it because the 
managers and coworkers don't really know what computer science is either.

There are little, isolated groups such as those on this list, who do have 
background schooling/training and knowledge about the issues.  But, it sure 
seems like there are so many broken software systems on so many consumer devices 
as well as out on the internet as "business apps", that something is still not 
right in the tooling and/or the training of software engineers.

This whole multi-core thing is a big problem in my books.  Especially when the 
developers are doing it themselves in each app they develop, and doubly so in 
integrations of multiple such applications/libraries.

The development of the Fork/Join stuff raises the bar on level of programming 
frameworks such that it makes it a little more possible to control things.  But, 
I still feel like we are creating ants and dropping them in the dirt, and then 
running around with poison, traps, shovels and the like, trying to keep them in 
or near the place we put them, and keep them alive, but not allowing them to 
proliferate too much such that the other ants are overwhelmed.

Something a lot higher level with much more specific patterns seems to still be 
needed, and as more people adopt the current leading edge tools, I'm betting 
that even more standardizations of helpful task management and work load control 
can occur.

Gregg Wonderly

>
> 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.economist.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