Re: Why multi-threading ?
Re: Why multi-threading ?
- Subject: Re: Why multi-threading ?
- From: Jeff Disher <email@hidden>
- Date: Mon, 26 May 2003 21:26:07 -0400
There are MANY reasons to multi-thread:
-obvious one is blocking tasks that need monitoring. Like reading from
a socket. It is annoying when this is done in the main thread because
the programs stops under poor network conditions (try using an IM
client on a wireless network, for example). Although another program
could do this for you, how do you get the information back from it? It
is the same problem as using another thread but you waste all that time
actually launching a new process and using kernel concepts like message
ports and signals which are slower than synchronizing on a semaphore by
no small margin.
-operations being performed on mutually exclusive data. If I am trying
to perform some kind of transformation on many independent images, for
example (like video frames), I can perform the operation in different
threads to maximize CPU utilization. Since the data being used doesn't
overlap, there is no problem with CPU caching. This would be much more
expensive to do as a separate task since I would have to launch another
instance of the program and then somehow send the frame to it.
Spawning another thread in the same memory space is MUCH cheaper
(especially on MACH where thread creation is nearly free, so I am told)
That said, however, you are correct for 90% of apps which don't need
the power of multiple CPUs, don't do too much blocking I/O, or mess
with overlapping data. While there are MANY REALLY GOOD reasons to
multi-thread, don't do it just for threading sake. You will know when
you need to do it.
In short, you need to realize how expensive process creation is versus
thread creation as well as the fact that synchronizing between threads
is not too difficult while synchronizing between programs is much more
difficult and MUCH more expensive.
Hope that helps,
Jeff.
On Monday, May 26, 2003, at 08: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.
Jeff Disher
President and Lead Developer of Spectral Class
Spectral Class: Shedding Light on Innovation
http://www.spectralclass.com/
_______________________________________________
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.