[PRL] "Threads Considered Harmful" in the news

Mitchell Wand wand at ccs.neu.edu
Tue Jan 23 07:45:29 EST 2007


This meme has now reached O'Reilly Radar, along with Erlang, Haskell, and
E.  Scheme needs to play in this space!!

--Mitch

http://radar.oreilly.com/archives/2007/01/threads_conside.html
Threads Considered Harmful [image:
Permalink]<http://radar.oreilly.com/archives/2007/01/threads_conside.html>
By Nat Torkington on January 23, 2007

Professor Edward A.
Lee<http://www.eecs.berkeley.edu/Faculty/Homepages/lee.html>from the
EECS department of UC Berkeley wrote The
Problem With Threads<http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.html>(
PDF <http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf>) last
year. In it, he observes that threads remove determinism and open the door
to subtle yet deadly bugs, and that while the problems were to some extent
manageable on single core systems, threads on multicore systems will magnify
the problems out of control. He suggests the only solution is to stop
bolting parallelism onto languages and components--instead design new
deterministically-composable components and languages.

This paper reflects two trends we see here at Radar: the first is towards
multicore systems and the growing importance of distributed execution; the
second is the increasing relevance of languages like
Erlang<http://en.wikipedia.org/wiki/Erlang_programming_language>,
Haskell <http://en.wikipedia.org/wiki/Haskell_programming_language>,
and E<http://en.wikipedia.org/wiki/E_programming_language>.
The growth of multicore is significant: if you want your program to run
faster, the days of buying faster hardware are coming to an end. Instead,
we're looking at a time when you must make your program run faster on more
(slow) hardware. Enter parallel programming, clusters, and their hyped big
brother "grid computing".

Google have obviously faced this problem and solved it with
MapReduce<http://labs.google.com/papers/mapreduce.html>.
Lee argues that this kind of coordination system is how we solve the problem
of threads' nondeterminism. It nicely parallels (heh) the way that database
sharding has become the way to solve scalability (see the Flickr war
story<http://radar.oreilly.com/archives/2006/04/database_war_stories_3_flickr.html>for
example). For this reason we're watching
Hadoop <http://lucene.apache.org/hadoop/>, the open source MapReduce
implementation, with interest. (There are also MapReduce implementations in
Perl<http://backpan.perl.org/authors/id/I/IW/IWOODHEAD/MapReduce-0.03.readme>,
Ruby <http://www.rufy.com/starfish/doc/>, and other languages)

MapReduce is built on a technique from the Lisp programming language. As the
need for speed forces us out of our single core procedural comfort zone,
we're looking more and more at "niche" programming languages for
inspiration. Haskell has quite the following among the alpha geeks we know (
e.g., the Pugs <http://www.pugscode.org/> project), and
OCaml<http://en.wikipedia.org/wiki/OCaml>has a small but growing group
of devotees. Then there was the huge interest
in Smalltalk at Avi Bryant's <http://smallthought.com/avi/> OSCON
talk<http://conferences.oreillynet.com/cs/os2006/view/e_sess/8942>last
year (SitePoint
blogged about it
here<http://www.sitepoint.com/blogs/2006/07/28/oscon-2006-web-heresies-the-seaside-framework/>
).
 Tags: erlang <http://radar.oreilly.com/tag/erlang>
google<http://radar.oreilly.com/tag/google>
hadoop <http://radar.oreilly.com/tag/hadoop>
haskell<http://radar.oreilly.com/tag/haskell>
languages <http://radar.oreilly.com/tag/languages>
mapreduce<http://radar.oreilly.com/tag/mapreduce>
ocaml <http://radar.oreilly.com/tag/ocaml>
parallel<http://radar.oreilly.com/tag/parallel>
programming <http://radar.oreilly.com/tag/programming>
smalltalk<http://radar.oreilly.com/tag/smalltalk>
threads <http://radar.oreilly.com/tag/threads>
-------------- next part --------------
HTML attachment scrubbed and removed


More information about the PRL mailing list