"the problem with threads"

Danny Mayer mayer at ntp.isc.org
Mon Sep 11 20:52:57 UTC 2006

Paul Vixie wrote:
>>> http://www.computer.org/portal/site/computer/menuitem.5d61c1d591162e4b0ef1bd108bcd45f3/index.jsp?&pName=computer_level1_article&TheCat=1005&path=computer/homepage/0506&file=cover.xml&xsl=article.xsl
>> So... to summarize:
>> - - Threads are bad
> no.  threads are the wrong solution to the problem they purported to solve.
> (does anybody but me remember when threads were called lightweight processes,
> and does anyone anywhere think that threads as they are today are lightweight?)

Well I don't think that threads are necessarily bad. Just like any other
tool, it's appropriate in some places and not in others.

Yes, I remember when threads were called lightweight processes, but then
I remember when Microsoft actually supported LDAP before they turned it
into Active Directory, which I, not so humerously, now call Heavyweight

>> - - All concurrent programs are provably bad
> that's not the way i read this article.  but speaking from bind9's experience,
> actually getting useful work out of N processors is very much more difficult
> than "use threads".

Agreed, but any method required to chop up an application into
manageable pieces that can run in parallel (for some meaning of
parallel) is not simple. Threads is just one attempt at doing that and
up-to-now has been the one with the most support. There are always
points in the application that one part has to wait for the results of
another before it can proceed and that's where you begin to lose. But
you cannot blame threads for that.

>> - - We don't really know what else to do
> i think the VLIW people believe that they know what else we should do :-).  i
> do not myself know what else we should do, unless it's the apache fork() model.

And how would that help?


More information about the bind-workers mailing list