[concurrency-interest] Economist article

Mohan Radhakrishnan mohanr at fss.co.in
Wed Jun 15 06:21:07 EDT 2011


>in places like JavaEE environments, where there as limited access to

This is still the case wherever we use app. servers. Right ? All the
software projects I have come across use them. I understand that this is
another hurdle in the path to the adoption of java.util.concurrent.

An example could be a ThreadLocal store that might not be cleaned up by
the pool implementation of the app. server. 


-----Original Message-----
From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of Gregg
Sent: Wednesday, June 15, 2011 2:02 AM
To: Joe Bowbeer
Cc: concurrency-interest
Subject: Re: [concurrency-interest] Economist article

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
address the issue of multi-threading through multi-processor machines,
average java programmer had no access to such machines except in places
JavaEE environments, where there as limited access to "threading".

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

There were not "path" analysis tools (and I still don't see them today)
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

Sure, the chip manufactures think that it is great to add more cores to
"processors" "more performant", but developers can get no benefits from
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
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
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

There are little, isolated groups such as those on this list, who do
background schooling/training and knowledge about the issues.  But, it
seems like there are so many broken software systems on so many consumer
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
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
that even more standardizations of helpful task management and work load
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
>     --tim
>     On Tue, Jun 14, 2011 at 12:53 PM, Joe Bowbeer wrote:
>         "Parallel programming, once an obscure niche, is the focus of
>         interest as multicore chips proliferate in ordinary PCs."
>         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
>         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

Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu

More information about the Concurrency-interest mailing list