Messages in this thread | | | From | Rob Landley <> | Subject | Re: Alan Cox quote? (was: Re: accounting for threads) | Date | Tue, 19 Jun 2001 14:18:03 -0400 |
| |
On Tuesday 19 June 2001 12:52, Larry McVoy wrote: > On Tue, Jun 19, 2001 at 05:26:09PM +0100, Matthew Kirkwood wrote: > > On Tue, 19 Jun 2001, Larry McVoy wrote: > > > ``Think of it this way: threads are like salt, not like pasta. You > > > like salt, I like salt, we all like salt. But we eat more pasta.'' > > > > This is oft-quoted but has, IMO, the property of not actually > > making any sense. > > Hmm. Makes sense to me. All it is saying is that you can't make a good > dinner out of a pile of salt. It was originally said to some GUI people > who wanted to use a thread per object, every button, scrollbar, canvas, > text widget, menu, etc., are all threads. What they didn't figure out is > that a thread needs a stack, the stack is the dominating space term, and > they were looking at a typical desktop with around 9,000 objects. Times, > at that point, an 8K stack. That was 73MB in stacks. Pretty darned stupid > when you look at it that way, huh?
I've seen worse.
Back around '93 or so I took a look at Linux and wound up putting OS/2 on my desktop instead of Linux for 2 reasons.
1) Diamond Stealth video card. It worked in OS/2, didn't work in Linux, and the reason was you guys couldn't get vendor support while IBM could. According to this list, it was entirely possible this sort of problem would NEVER be addressed. (We got around it with reverse engineering and critical mass, but at the time hardware was changing way faster than we could keep up with it.)
2) Not only did Linux not have threads (at all), it didn't plan to have threads, and anybody who brought up the idea of threads was dismissed. Considering this was long before clone, and SMP hardware was starting to come into the high and and looked like it might wind up on the desktop eventually (who knew MS would keep DOS around another ten years, unable to understand two processors, to displays, two mice, two keyboards, and barely able to cope with two hard drives under a 26 letter limit...)
So I wound up work at IBM doing OS/2 development for a couple years. On a project called Feature Install, which was based on a subclassed folder in the workplace shell (object oriented desktop). The idea was you fill up a folder with files, drag and drop them from diskette to desktop, and they install themselves automatically. (Went out the window when a single install object had to span two disks, but oh well. By then, they were stuck with the design. I inherited it after a year or two of scar tissue had accumulated.)
They created THREE threads for every single object, and they objects could nest arbitrarily deep. (Modular installs with sub-components.) The OS had a default of 1024 threads (expandable to 4096, I believe, before they hit a 64k limit somewhere in the coding). When they made up a test object hierarchy for all the components of the entire OS, it created so many threads the system ran out and got completely hosed. I had a command line window open, but couldn't RUN anything, since anything it tried to spawn required a thread to run. (Child of the shell.)
One three finger salute later, the desktop comes back up automatically, with this nasty tangle of objects STILL there, and of course hoses itself AGAIN as the desktop instantiates all those objects in memory with their three threads apiece, and runs out again...
Those were the days. If I remember correctly, I replace ALL those threads with a single thread doing all the work, a mutex protected linked list of work to do, and an event semaphore to tell it to do it.
> Nobody is arguing that having more than one thread of execution in an > application is a bad idea. On an SMP machine, having the same number of > processes/threads as there are CPUs is a requirement to get the scaling > if that app is all you are running. That's fine. But on a uniprocessor, > threads are basically stupid.
Sometimes they're an easy way to get asynchronous behavior, and to perform work in the background without the GUI being locked up. But the difference between "processes" and "threads" there is academic. Processes with shared memory and some variant of semaphores to avoid killing each other in it. Same thing.
And I think the most I've ever REALLY used is about three for a whole program. (Unless you're talking about a server with a thread pool handling connections. And yeah that could be done with poll and non-blocking I/O, but not if you're shelling out to ssh and such...)
> The only place that I know of where it is > necessary is for I/O which blocks. And even there you only need enough > to overlap the I/O such that it streams. And processes will, and do, > work fine for that.
And nonblocking GUI elements, and breaking up work for multiple processors, and probably a few other things.
But I think the MAIN difference between the two camps is that the people who despise threads consider them to be a lot different from processes, and the people who like threads consider it a semantic argument. I worry about cache trashing with too much shared data in an SMP system, but like the fact you automatically have synchronization primitives in a threading environment which might not be there if you're just dealing with processes.
I've used the filesystem for synchronization. Back around 1991 I wrote my own fidonet compatable multinode BBS under DOS with desqview, including the mail tosser, from scratch in Borland C++ with nothing but file locking to keep the instances from killing each other, and I got 30 messages/second throughput on a 33 mhz 386. The mail tosser could catch new posts in the middle of a stream of incoming messages from the network without ever having to look at an individual message message twice, and packed the message bases during the act of posting. (And a bunch of fancy features I won't bore you with, especially the way delete worked.)
After doing all that with stone knives and bearskins, I -APPRECIATED- a 32 bit flat memory model with threads. :)
> I think the general thrust of us ``anti-thread'' people is that a few > are fine, a lot is stupid, and the model encourages a lot. It's just > like perl5, C++, pick-your-favorite-feature-rich-language in that > exceptional programmers will do a good job with the problem but average > programmers will do a horrible job. Given that there are only a few > exceptional programmers and a never ending wave of average programmers, > the argument is that one should tailor the paradigm for the common case, > not for the exceptional case.
There has not been and never will be a language in which it is the least bit difficult to write bad programs.
I don't remember who said that, but it should be on your list. (Ask Nancy Lebowitz.)
Bondage and discipline languages that enforce somebody's idea of good programming practice usually just result in WORSE bad programs, and fewer good programs written by people who know how to play with fire without burning themselves. Saying you can't have threads because they can be misused and "you shouldn't program that way" would be truly dumb. (Turned ME off for a couple years, anyway.)
Rob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |