Re: Why multi-threading ?
Re: Why multi-threading ?
- Subject: Re: Why multi-threading ?
- From: Dietrich Epp <email@hidden>
- Date: Tue, 27 May 2003 14:43:59 -0700
On Tuesday, May 27, 2003, at 06:28 US/Pacific, Chris Hanson wrote:
On Tuesday, May 27, 2003, at 07:23 AM, Dietrich Epp wrote:
One thread deals with the network, often blocked. One thread deals
with everything else. This way I don't get disconnected when I fail
to pong because the user is running a script, or saving a file, etc.
If this were single-threaded, I would have to do something like
polling which is pretty damn inefficient. Instead, when data is
available, the network thread unblocks and processes it without any
intervention from the UI thread.
There's another way to do this as well: Events. If your network stack
delivers events to your application code when things requiring its
attention happen, you can be single-threaded and also not poll.
I mentioned this. Read the second paragraph from the bottom in my last
post. The problem is that it's not portable and
This is how Open Transport worked on the classical Mac OS. It's also
the sort of API simulated using threads & blocking I/O behind the
scenes by many Cocoa facilities (-[NSFileHandle
readInBackgroundAndNotify] for example).
Multithreaded servers have scalability problems. That's why FreeBSD
has kernel queues & events.
What are these problems? How could two threads possible scale less
well than one thread? Perhaps you mean that a thread per connection
doesn't scale well. It doesn't. But I don't program that way, and I
don't know anybody who does.
Basically, break the program into two parts: One part interacts with
the user. One part interacts with other computers on the network.
This is good design, no? It is more difficult to design one thread to
do two separate tasks simultaneously than two threads to simply focus
on one task.
Also, think about the performance. Let's say you have an application
that at times heavily relies on the CPU, network, and user interface.
Either you create one thread which handles everything, sometimes
CPU-bound, sometimes network-bound, ... or you create three threads and
let the kernel manage resources for you. You can then optimize each
one without having to worry about the others.
I'm not trying to suggest multithreading is never a good idea. In
fact, I've used it quite a bit to good effect. But there are other
mechanisms by which to achieve most of the same goals. (One that
multithreading is necessary for is spreading the work of one process
across multiple CPUs.)
Right... at least 90% of all applications shouldn't be multi-threaded.
But those 90% usually aren't anyway. Unfortunately, there doesn't seem
to be this kind of discussion on when threads are appropriate on the
web, only web pages devoted to the hows.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.