Re: Why multi-threading ?
Re: Why multi-threading ?
- Subject: Re: Why multi-threading ?
- From: Wade Tregaskis <email@hidden>
- Date: Tue, 27 May 2003 12:37:03 +1000
I'm no expert on this, so I'll hand out salt out the door, so to speak.
The technical response has already been posted, but failed to fully
address your conceptual problems.
I think the essential purposes of multi-threading in a 'modern' OS are
to increase user responsiveness and parallelism.
Taking the latter first, the simplest form of parallelism means running
multiple processes simultaneously, ala the 'innovative' OS 6
MultiFinder. But 'processes' is in fact the wrong word - 'tasks' is
more appropriate in a human sense. And because any given program may
well perform multiple tasks, some independently, it may need to be
multi-threaded in order to achieve the principle aim of parallelism.
This is parallelism in the sense not that it may speed things up at
all, but that the user can perform two actions within the same program,
at the same time - e.g. open an image in Photoshop while performing a
lengthy filter on an already open one.
The aim for responsiveness is not too well realized in MacOS X, but I
believe BeOS [among others] does it well. BeOS in particular does so
in the most obvious way - by enforcing the design of highly
multi-threaded programs. In an unrealistic example, you might design a
system so that each discrete user input performs it's operation in a
new thread. So clicking a button several times will spawn several
threads, each performing the appropriate action. Consequently, you
could perform any non-dependent operation at any time, irrelevant of
what other processing is already going on. Thus, the program is
completely 'available', which is an important aspect of responsiveness.
The only time the threads clash is when two or more need access to a
shared resource. In this case they wait. But this is no longer a UI
responsiveness issue, but more a resources [and design] one.
Hopefully that makes sense.
There are several school's of thought on multi-threading. You are
correct in stating that a multi-threaded program can only be slower
than a single-threaded one, in a simple linear sense. But when you
consider that a computer is inherently a parallel machine - lots of
events occurring simultaneously - and that a lot of event processing
simply involves the dispatching of further events and waiting for more
events back, how you measure performance moves from raw cpu usage to
how quickly you can operate on small, predominately time-dependent
events. In a single-threaded system, you could starve out a long list
of events if the current one takes a long time to process. When you do
finish that one and move to the next, you may find you have to send
away for data anyway. Had you adopted a multi-threaded design, you
could have spent that time waiting on data while processing the first
event anyway.
Ultimately, if you follow this to it's conclusion you end up down at
the microprocessor principles, looking at schedulers and all those sort
of basic principles. So, if you're really interested in threading
issues, I'd suggest you start with an intro to microprocessors, and
work up from there.
Wade Tregaskis
-- Sed quis custodiet ipsos custodes?
_______________________________________________
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.