Re: Why multi-threading ?
Re: Why multi-threading ?
- Subject: Re: Why multi-threading ?
- From: "Dennis C.De Mars" <email@hidden>
- Date: Mon, 26 May 2003 19:19:48 -0700
I think multi-threading is probably overused, because developers want
to use it and minimize in their minds the problems it can introduce.
The main problems are:
1) The simple presence of multiple threads greatly increases the
difficulty of writing correct code.
2) (and this is the kicker) Presence of multiple threads makes it
virtually impossible to verify that your code is correct. Without
multiple threads you at least have a high degree of determinism and can
be fairly assured that a given set of inputs will always produce the
same set of outputs (verification then becomes the problem of coming up
with a set of inputs that will cover a sufficient number of situation
to flush out any lurking bugs). With multiple threads, you can run the
same program a thousand times with the same set of inputs and get the
right output, then fail on the 1001 try. Or, a program can run
successfully every time on a given computer, for months or years, and
then you move it to another machine and it crashes every time you try
to run it there.
I somewhat disagree with you post, though, in that you imply protected
memory would solve the problem, which would imply that the problem is
threads inadvertently stepping on memory it is not supposed to, whereas
I have found the big problem is race conditions. It is true that some
sort of messaging protocol involving the use of message queues can
prevent some of these problems, but you could use messaging between
threads.
I would try to avoid the use of threads where possible. One reason to
use them is to allow the use of multiple CPUs for CPU-intensive chores.
In this case you might be able to use multiple processes, but I think
the main reason to use multiple threads rather than multiple processes
would be where the overhead is considered to be too high; if you are
crunching on a large amount of data, it may be impractical to do the
processing in multiple processes where performance is an issue.
Anyway, due to my experiences with the difficulty of debugging
multiple-threaded programs I personally would recommend the following
rules:
1) Eschew multiple threads if possible (that is, don't use
multi-threading for the sake of multi-threading). Sometimes it is just
as easy to construct a single-threaded algorithm to do the same thing.
2) If it looks like it would be too complicated to go single-threaded,
make sure that, if you haven't already, you read one or two good books
on multi-threaded programming. Make sure you know the gotchas before
you start.
3) If you possibly can, test your code on a dual CPU machine. This can
flush out a lot of race conditions that would seldom show up on a
single CPU machine.
I have a project that I will probably use multi-threading for,
specifically because I want to utilize multiple CPUs to reduce
processing time. I'm not considering going with multiple processes
though, because it would complicate the program considerably and it
wouldn't necessarily remove the possibility of race conditions.
- Dennis D.
On Monday, May 26, 2003, at 05:48 PM, publiclook wrote:
In my experience with multi-threading going back to Ada 83 and most
recently with Java and C++ systems, why does anybody bother ?
Let me clarify: In my experience, multi-threading makes writing
correct code many times harder. It is nearly impossible to document
your intentions in the source code because almost by definition,
someone reading your code will be unaware of other things happening
concurrently when the code they are looking at executes.
Multi-threading adds a huge overhead to common operations due to
system calls for mutexes/semaphores and in a true multi-processor
system plays havoc with processor caches etc. For example, if two
processors are simultaneously using data in the same cache line then
typically neither processor can cache the data and memory accesses go
from being a few cycles to a massive number of cycles. Doesn't the
memory access impairment cancel any benefit of multi-threading in the
common cases?
If there are long running background "tasks" to perform, why not run
them as separate tasks with separate protected memory ? Why not use
message queues, signals, distributed messaging, mach messaging or
whatever as the communication between tasks if you are going to end up
using them between threads anyway ? Protected memory is a GOOD thing
that was a long time coming to Mac OS and it seem the first thing
people want to do is deliberately bypass it with multi-threading
instead of multi-tasking.
So why does anybody bother with multi-threading ? What am I missing ?
_______________________________________________
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.
_______________________________________________
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.