I agree that there are very few situations in which more than a handful of kernel threads is needed. In almost every case, a 1000 kernel-threaded process is bad programming. But even in context, it still reads as elitist to me?
> the IBM paper), that if your application depends on huge numbers of
> threads, you're always going to keep bumping up against the schedule
+r?
> a lot of people throw lots of threads at a problem and it can really
+
> be bad design.
That is the least of your worry. 1000 threads is 8Mb of kernel stacks,
+ and
enough switching of tasks to be sure you might as well turn most of yo
+ur
cache off. A computer is a state machine. Threads are for people who c
+ant
program state machines.
Unfortunately the link to the IBM paper referred to above is a dead end*. That sounds interesting and may have cast a different light on things?
*IBM have been shuffling their links again. Why do corporations do that I wonder? MS are always doing the same damn stupid trick.
Then again, when I worked at IBM, I remember going through 4 offices moves and three department name changes in 10 months. Two of them (offices and dept. names) in a 1 month period! The really stupid part about it is that each time I moved to a different (identical or mirror image) office within the same corridor!.
Too many people with not enough to do, so they "shuffle resources" as a make-work exercise. People, offices, web pages, they're all the same thing--just resources.
With respect to the difficulty of threads versus the difficulty of state machines. In the type of programming that Mr.Cox does, state machines work. Ie. In those scenarios where events arrive every few milliseconds and the actions required take (less) milliseconds, its a natural fit. (Still hard, but natural.)
In application programs where some events require 1/10th seconds response times, and others take 10 of seconds, or minutes, or hours, breaking the long bits up into 1/10th second lumps so you can service the fast bits in a timely manner is a nightmare.
Conversely, the typical application scenario for threading; one thread runs a state machine to service a GUI; whilst another thread issues DB queries, waits for the response and then supplies the retrieved data to the gui in nice small chunks via it's event queue; whilst another thread monitors a directory for the arrival of a file and informs the GUI it's there; and another is started to read that file into memory and feed into a display buffer or edit widget for the user to mess with. Threads are a natural fit for this. No where in that scenario is there any need for locking. No opportunities for deadlocks.
Even proving correctness is simple. Each threads code is a simple loop, blocking at the top waiting for it's start event and running linearly through it, processing, before looping back to the top. Each threads code can be tested in isolation of the others. The only thing open to timing errors is the initiation event--and that's controlled by the user, via the state machine running in the GUI thread.
Try writing that scenario as single threaded state machine and getting it to run efficiently on a range of different spec'd processors. Having tried, I know it's a nightmare.
Threading does not have to be hard. Avoiding deadlocks is easy:
...
{ lock $variable; $x = something }
...
Those curlies delimit the life of the lock. If you never try to acquire two locks concurrently, you can never deadlock.
Now, if every time you want to access shared state, you are going to lock it, do your stuff and then unlock before doing anything else. Then the 'system' can do that for you. It knows which variables are shared, and it can bracket every access to those variables with the locking. Then the whole shared state problem goes away. You simply declare the data shared and the system (compiler, interpreter, whatever) always remembers to lock and unlock the variable each side of that access.
No, this is not the fastest way to used shared state, but when the alternative is sending the shared values back and forth through sockets or other interprocess mechanism, it's still way faster. And simpler.
The other main argument that is claimed to make threading hard is debugging. This is incorrect. The problem that makes debugging threads hard, is bad coding. If you try to write close coupled routines and run them across threads, you make a world of grief for yourself. So don't do that. Close coupled code is a no-no anywhere, threads exacerbates the problem for sure, but the problem has to exist in the first place.
Debugging threaded code should be, and can be simple. Much simpler than state machines. The code in each thread should run perfectly happily as a standalone process with shared variables being no different to reading data from a db; or a file, or from a socket. For testing, substitute a tied var that randomly takes on values in the required range (and out of range forerror handling checks) each time you read it; and does nothing in particular ('cept maybe waits for a while) when you write to it. There is a complete method for testing all threaded application code.
What about timing issues I hear someone ask. Simple, there are none. If there are, you are trying to synchronise threads and that's silly. So don't do that.
Even this threaded MapReduce problem that floating around is trivial. It can be written in 20 lines of code using Perl and iThreads and existing, well known and tested modules.
Things are more complicated in C. There, it is possible to scribble all over memory. That's bad enough and hard enough to track down in a single threaded program. It is a nightmare in a multi-threaded program. But Perl doesn't let you do that without really, really going out of your way to do so, or as a the result of a interpreter bug.
Threading is perceived of as hard because whenever it comes up, all the "we don't need no stinkin' threads" crowd trot out the same tired old scenarios in which threads can cause deadlocks and corruption without ever mentioning that you only arrive at those situation if you do something stupid. And that just as with any other form of coding, if you don't do the stupid things, you don't get the problems.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| 