On Fri, 2005-07-29 at 14:29 -0700, Robert Simpson wrote: > 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.
Agreed. > > 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. Like chainsaws, gotos aren't useful for every task. > 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. Agreed. > > 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. Hence the point. Look at the parent and grandparent. There are many people posting on this thread that _believe_ that threads are a necessity. > 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. Right. But they don't ask that. They say "I found a bug in SQLite when using threads".
