Received: by 10.101.171.23 with SMTP id y23mr5421485ano.47.1319371385319;
Sun, 23 Oct 2011 05:03:05 -0700 (PDT)
X-BeenThere: javaposse@googlegroups.com
Received: by 10.101.206.2 with SMTP id i2ls21112278anq.1.gmail; Sun, 23 Oct
2011 05:02:58 -0700 (PDT)
Received: by 10.101.179.32 with SMTP id g32mr1523133anp.30.1319371378635;
Sun, 23 Oct 2011 05:02:58 -0700 (PDT)
Date: Sun, 23 Oct 2011 05:02:57 -0700 (PDT)
From: opinali <opin...@gmail.com>
Reply-To: javaposse@googlegroups.com
To: javaposse@googlegroups.com
Message-ID: <15772953.143.1319371377375.JavaMail.geo-discussion-forums@yqnv12>
In-Reply-To: <1319284000.29770.9.camel@launcelot.russel.org.uk>
References: <11825885.931.1319138826692.JavaMail.geo-discussion-forums@yqkb19>
<8380998.3642.1319205181669.JavaMail.geo-discussion-forums@yqgn17>
<6577835.353.1319245997323.JavaMail.geo-discussion-forums@vbmh5>
<CAOphgJC5gBwhHjpWL3-a-M_sBW7re6dwXih_mcO6sn7+a4SROw@mail.gmail.com>
<23695231.41.1319283163479.JavaMail.geo-discussion-forums@yqoh14>
<1319284000.29770.9.camel@launcelot.russel.org.uk>
Subject: Re: Models of Parallelism [ was Re: [The Java Posse] Re: Fork/Join
criticism ]
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_141_28969313.1319371377370"
------=_Part_141_28969313.1319371377370
Content-Type: multipart/alternative;
boundary="----=_Part_142_12442850.1319371377371"
------=_Part_142_12442850.1319371377371
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
On Saturday, October 22, 2011 7:46:40 AM UTC-4, Russel wrote:
>
> On Sat, 2011-10-22 at 04:32 -0700, opinali wrote:
> [ . . . ]
> > The single serious criticism I've ever heard about j.u.c. and the
> continuing
> > work of JSR-166, is that it furthers the paradigm of shared-memory
> > concurrency. But, like it or not, it's the appropriate thing to do at the
> (...)
>
> Well here we have a real bone of contention. Java reified shared memory
> multithreading in the early 1990s. It was an error then and is certainly
>
We don't need to debate this -- the past is the past, and like it not this
is the paradigm of concurrency embedded in Java and in billions of existing
LOC of Java apps, this this must be supported forever and also improved
continuously in the extent that's possible. I don't claim that we cannot
have a new concurrency model as an additional option (hi @Kirk), I just say
that the existing system must keep moving'. Deprecating the shared-memory
concurrency model is not realistic - it's not like, say, deprecating entity
beans for JPA or deprecating Swing for JavaFX; it's not a single library
that is only used by a subset of applications, it's a core feature that is
used directly or indirectly by 100% of all code (apps, core libs,
third-party libs... including the implementation of alternative languages
and concurrency frameworks). Even the introduction of j.u.c. in JDK 5 was
not a radical break with the past; I for one, had significant legacy code
written with straight threads/monitors or with other libs (like Apache
commons-pool) that I was able to quickly review to benefit from j.u.c.
> an error now -- at least as being pushed as the "one true way" of
> concurrency since it makes parallelism very hard. Why should it remain
> the "one true way" in Java? It is this closed mindset that is a big
> problem with Java. Java should have actor libraries, dataflow
> libraries, CSP, that applications folk use. Certainly shared memory
>
I agree, but I think this kind of innovation already happens in the right
places - the JVM-languages communities (Clojure, Scala etc.). We Java-lang
diehards may complain about learning and adopting a new language as
precondition for a new concurrency model (for one, I'm envious of Clojure's
persistent collections), but that's the only *good* way to do it, because
Java lacks even the slightest amount of support for these other models. For
one thing, there's no real support for immutability ('final' is not good
enough, we need full "constness" support a la C++).
Something like an actor library could be added to core Java, but
1) who would shoulder the effort? Oracle is busy enough improving the core
paradigm (as it should), including hard low-level optimizations like lock
elision etc. Concurrency is not everything, there's a ton of other
big-ticket RFEs that are pet ideas of many hackers, should Oracle do them
all?
2) and even assuming that Oracle has the resources to implement all our pet
RFEs, should all of them be thrown into the JRE? Many people already
complain of bloat when APIs that *are* used by a massive number of apps,
like XML / Web Services stuff, are added to the core...
3) so maybe they add actors, only to make 50% of the community pissed of
that they didn't pick some other next-gen concurrency idea, such as STM?
4) what to do when people start claiming for language syntax support for the
new concurrency system? Add tons of extra syntax on top of the already big
and hard-to-evolve Java language?
A+
Osvaldo
> multithreading is an important framework level technique, but no
> applications programmer should ever have to use such a low level model
> of concurrency and parallelism.
>
> GPars (http://gpars.codehaus.org) brings all of these things to Groovy
> and Java programmers. JCSP is a CSP framework for Java. DataRush is a
> commercial offering from Pervasive that offers dataflow. These models
> thrash explicit use of shared memory multithreading for applications
> development.
>
> Please can we ditch the idea that Java means using shared memory
> multithreading and that to use other models we have to use other
> languages. It is not true and it is damaging in the face of ubiquitous
> parallel hardware.
>
> --
> Russel.
>
> =============================================================================
> Dr Russel Winder t: +44 20 7585 2200 voip: sip:russ...@ekiga.net
> 41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@russel.org.uk
> London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
>
>
------=_Part_142_12442850.1319371377371
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br>On Saturday, October 22, 2011 7:46:40 AM UTC-4, Russel wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">On Sat, 2011-10-22 at 04:32 -0700, opina=
li wrote:<br>[ . . . ]<br>> The single serious criticism I've ever heard=
about j.u.c. and the continuing <br>> work of JSR-166, is that it furth=
ers the paradigm of shared-memory <br>> concurrency. But, like it or not=
, it's the appropriate thing to do at the (...)<br><br><p>Well here we have=
a real bone of contention. Java reified shared memory<br>multithread=
ing in the early 1990s. It was an error then and is certainly<br></p></bloc=
kquote><div><br>We don't need to debate this -- the past is the past, and l=
ike it not this is the paradigm of concurrency embedded in Java and in bill=
ions of existing LOC of Java apps, this this must be supported forever and =
also improved continuously in the extent that's possible. I don't claim tha=
t we cannot have a new concurrency model as an additional option (hi @Kirk)=
, I just say that the existing system must keep moving'. Deprecating the sh=
ared-memory concurrency model is not realistic - it's not like, say, deprec=
ating entity beans for JPA or deprecating Swing for JavaFX; it's not a sing=
le library that is only used by a subset of applications, it's a core featu=
re that is used directly or indirectly by 100% of all code (apps, core libs=
, third-party libs... including the implementation of alternative languages=
and concurrency frameworks). Even the introduction of j.u.c. in JDK 5 was =
not a radical break with the past; I for one, had significant legacy code w=
ritten with straight threads/monitors or with other libs (like Apache commo=
ns-pool) that I was able to quickly review to benefit from j.u.c.<br> =
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex;=
border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><p>an error=
now -- at least as being pushed as the "one true way" of<br>concurrency si=
nce it makes parallelism very hard. Why should it remain<br>the "one =
true way" in Java? It is this closed mindset that is a big<br>problem=
with Java. Java should have actor libraries, dataflow<br>libraries, =
CSP, that applications folk use. Certainly shared memory<br></p></blo=
ckquote><div>I agree, but I think this kind of innovation already happens i=
n the right places - the JVM-languages communities (Clojure, Scala etc.). W=
e Java-lang diehards may complain about learning and adopting a new languag=
e as precondition for a new concurrency model (for one, I'm envious of Cloj=
ure's persistent collections), but that's the only *good* way to do it, bec=
ause Java lacks even the slightest amount of support for these other models=
. For one thing, there's no real support for immutability ('final' is not g=
ood enough, we need full "constness" support a la C++).<br><br>Something li=
ke an actor library could be added to core Java, but<br><br>1) who would sh=
oulder the effort? Oracle is busy enough improving the core paradigm (as it=
should), including hard low-level optimizations like lock elision etc. Con=
currency is not everything, there's a ton of other big-ticket RFEs that are=
pet ideas of many hackers, should Oracle do them all?<br>2) and even assum=
ing that Oracle has the resources to implement all our pet RFEs, should all=
of them be thrown into the JRE? Many people already complain of bloat when=
APIs that *are* used by a massive number of apps, like XML / Web Services =
stuff, are added to the core...<br>3) so maybe they add actors, only to mak=
e 50% of the community pissed of that they didn't pick some other next-gen =
concurrency idea, such as STM?<br>4) what to do when people start claiming =
for language syntax support for the new concurrency system? Add tons of ext=
ra syntax on top of the already big and hard-to-evolve Java language?<br><b=
r>A+<br>Osvaldo<br> </div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); paddin=
g-left: 1ex;"><p>multithreading is an important framework level technique, =
but no<br>applications programmer should ever have to use such a low level =
model<br>of concurrency and parallelism.</p><p>GPars (<a href=3D"http://gpa=
rs.codehaus.org" target=3D"_blank">http://gpars.codehaus.org</a>) brings al=
l of these things to Groovy<br>and Java programmers. JCSP is a CSP fr=
amework for Java. DataRush is a<br>commercial offering from Pervasive=
that offers dataflow. These models<br>thrash explicit use of shared =
memory multithreading for applications<br>development.</p><p>Please can we =
ditch the idea that Java means using shared memory<br>multithreading and th=
at to use other models we have to use other<br>languages. It is not t=
rue and it is damaging in the face of ubiquitous<br>parallel hardware.</p><=
p>-- <br>Russel.<br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<wbr>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<wbr>=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>Dr Russel Winder &=
nbsp;t: +44 20 7585 2200 voip: <a>sip:russ...@ekiga.net</a><br>41 Bu=
ckmaster Road m: +44 7770 465 077 xmpp: <a>rus...@russe=
l.org.uk</a><br>London SW11 1EN, UK w: <a href=3D"http://www.russel.=
org.uk" target=3D"_blank">www.russel.org.uk</a> skype: russel_winder<=
br></p><p></p><p></p><p></p></blockquote>
------=_Part_142_12442850.1319371377371--
------=_Part_141_28969313.1319371377370--
Message from discussion Models of Parallelism [ was Re: [The Java Posse] Re: Fork/Join criticism ]
| Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy |
| ©2013 Google |