Like it or not, you still don't have any idea what you are doing. They
[threads] are never the only solution, and they are rarely appropriate.
I'm certain I'm not being entirely clear on just how rare it is: Threads
so rarely help that the programs that they CAN help don't often use
them, and the programs that it DOESN'T HELP- nay actually hurts, are the
ones using threads.
I wouldn't generalize to *quite* this extreme, being as I have not written
nor reviewed even a small fraction of a percent of the millions of programs
written on various platforms. However, I will say this:
Threads are a tool ... sortof like a chainsaw. Used properly, they can save
you time and accomplish your goal. In the hands of an expert, you can even
make some impressive art. Well, perhaps the latter only applies to
chainsaws, but you get the idea. In the hands of the ignorant or
inexperienced, you can easily lop off an arm or a leg, or getting back to
threading, seriously undermine the integrity of your code. Threading, like
chainsaws, can be dangerous if not used properly.
20 years ago, people said the exact same thing about goto- the places
where it can help are in programs that don't often use them, but the
places where it DOESN'T HELP- and actually hurts, are the ones using
goto.
I used goto's back when I was programming on the Vic-20 and I only had 3k of
RAM to work with -- every byte was valuable back then. I also couldn't
understand the various branches of my code a week later when I went to debug
it, so I had a love-hate relationship with gotos.
I don't use them primarily because they, like threads, are easily abused and
can potentially make your code extremely hard to follow. Case in point, one
of the older programmers in my office uses goto's liberally (on one project
we discovered a 1:9 ratio of goto's in his code -- meaning 1 goto for every
9 lines of code on average). His code is unintelligible. He has labels
inside his for() loops and goto's jumping in and out of them. He's got code
leapfrogging all over creation, and its the sickest ugliest thing I've ever
witnessed. Who in hell even knows if the stuff works -- its all but
impossible to understand without running it.
Now, if you're feeling like you're on a high horse, go ahead: point out
a single common platform where threads are the necessity.
That argument is silly. There exist no *platforms* where multithreading is
a necessity. The platform doesn't dictate whether threading is useful or
warranted for a given application. The programmer decides that.
[snip]
No. In order to use threads with SQLite you need to know how to use
threads. In order to use threads with ImageMagick, you need to know how
to use threads. In order to use threads with PostgreSQL you need to know
how to use threads. In order to use threads with libmodplug you need to
know how to use threads.
Notice a common theme? All of these libraries require the user do their
own serialization, and yet people continue to ask "how do I make
OpenLDAP work with threads" when they really mean "how do I use
threads."
The real problem many coders encounter when writing multithreaded
applications is that some of the underlying libraries they may be using may
include optimizations that make the library inherently unsafe in a
multithreaded environment. For example, a library that uses a global
variable to store a handle to a database file, and all instances of the
object simply refer back to that global handle. You could code all the
synchronization objects you like and make sure all the object instances
never cross a thread boundary, but in the end if the underlying library's
objects are all sharing a global variable unbenknownst to you, then your
code is still going to have a potentially lethal race condition. I think
*this* is the major issue people are concerned about when they come to the
SQLite list asking if SQLite is threadsafe.
There isn't any grey area here. Threads are complicated- so complicated
that they screw up otherwise promising programmers into thinking that
they're necessary and/or easy, when they're clearly neither.
I absolutely 100% agree. Threads are dangerous and their benefits should be
weighed before applying them to your application(s). Personally, I've
written quite a few programs that have benefitted significantly from
multithreading, most of them server-based. Those particular apps would've
crashed and burned horribly when placed under a heavy load without using
threads, so one could argue that they were not only beneficial but necessary
to their success.
Robert Simpson
Programmer at Large
