[concurrency-interest] Economist article
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.
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
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
> 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
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
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
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
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
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
right in the tooling and/or the training of software engineers.
This whole multi-core thing is a big problem in my books. Especially
developers are doing it themselves in each app they develop, and doubly
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
I still feel like we are creating ants and dropping them in the dirt,
running around with poison, traps, shovels and the like, trying to keep
or near the place we put them, and keep them alive, but not allowing
proliferate too much such that the other ants are overwhelmed.
Something a lot higher level with much more specific patterns seems to
needed, and as more people adopt the current leading edge tools, I'm
that even more standardizations of helpful task management and work load
> 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
> that languages, programmers, and educators are unexpectedly
> because of the proliferation of multicores on the desktop,
> of the Economist probably wouldn't know about without being in the
> 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."
> The article mentions Scala but not java.util.concurrent.
> To me, this problem still seems more "derivative" of the
> 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
> problem looks like a multi-headed nail?
> Maybe my mobile-shaded perspective will change now that
> shipping on handsets...
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu
More information about the Concurrency-interest