[concurrency-interest] Economist article

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


Hi,

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

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. 

Thanks,
Mohan

-----Original Message-----
From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of Gregg
Wonderly
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
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.economis
t.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

_______________________________________________
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