Re: [Plib-users] Threading

[Sam S. <sa...@sp...>]

----- Original Message -----
From: "Curtis L. Olson" <cu...@me...>
To: <pli...@li...>
Sent: Wednesday, April 11, 2001 3:45 PM
Subject: Re: [Plib-users] Threading


> Do know that threads are not necessarily nirvana, and unless you
> really know what you are doing and exactly what the threading will
> accomplish for you in advance, I'd recommend staying away from them as
> long as you can.  You can do an amazing amount without them if you
> try.  If you do add threading, know that you are introducing a new
> layer of complexity in terms of software design, as well as in terms
> of debugging, and many assumptions your code may have made in the past
> might come around to bite you once you add threading ... and bite you
> in subtle hard to debug ways ... at inopportune times ...
>
> But heck, I'm not listening to my own advice so I suppose I shouldn't
> expect anyone else to ... :-)

Heh, yeah debugging threads can be a bit of a nightmare.  One thing I've
found that really helps is to make sure you are running on a multiprocessor
machine when you do all your debugging!  It really helps you stumble upon
race conditions and update conflicts that much earlier.  And what Curtis
says is correct - threads are not nirvana.  I've worked on a couple of
projects that (through naivety) started out multi-threaded, and then got all
the threads ripped out halfway through. :)

(When you're starting out it's very easy to make these mistakes - a server
application?  I'll have a new thread handle each client! doh! This stuff can
get complicated very quickly on server applications.  On an SMP box it makes
sense to have X number of threads each containing Y clients.  But tuning for
maximum efficiently is hard - what is the optimum number of threads for the
hardware your program finds it running on? 2, 4 or 8+ CPUs?  What's the
optimum number of clients per thread?  What about clients that are doing a
lot of data transfer Vs. those doing relatively little? And then you have to
start worring about making sure the access locks to your central datapool
are fine grained.  Whoops, getting a little OT here...)

My advice is - unless you are *absolutely* sure you need threads - stick
with single threaded apps.  If there are some areas where you believe
threading may help you then structure your design for a multi-threaded app
but code it single-threaded.  Get that version running and debugged and then
go multi-threaded.  BUT this does require careful design!

As an example, the "heap of concept work" that is SpaceThing
(www.spacething.org) is single threaded, but almost all the object access is
semaphore protected.  Currently in the release builds the locking functions
are replaced with inline "do nothing" functions.  In the debug builds a
couple of defines can switch it into multi-threaded mode - but there's all
sorts of problems with race-conditions and stuff that I keep encountering.
At the moment it doesn't seem worth the effort to hunt them down.

Sam

Disclaimer: Post written after a long haul coding session followed by curry
and a lot of beer.  I'll probably read this in the morning and think wft?!
:)