Re: Processes vs. Threads in Cocoa software architectures
Re: Processes vs. Threads in Cocoa software architectures
- Subject: Re: Processes vs. Threads in Cocoa software architectures
- From: Jeff C <email@hidden>
- Date: Wed, 6 Sep 2006 22:50:27 -0400
On Sep 6, 2006, at 9:38 PM, Erik Buck wrote:
On Sep 6, 2006, at 5:51 PM, John Stiles wrote:
On Sep 6, 2006, at 2:45 PM, Shawn Erickson wrote:
You either value memory protection or you don't.
As soon as you have ONE thread in your process your can screw up
your
own processes memory just as bad as you could with multiple threads.
I agree; multiple threads don't increase your chances of stomping
memory. It's just not an issue.
There are certain classes of bugs that show up more in threaded
apps, but I wouldn't consider memory stomping to be in that list.
Usually it's timing-sensitive bugs that get worse—and often it's
bugs that would have happened either way, but the threading makes
the problem happen more quickly, which is actually a good thing
from a debugging perspective.
This has to do with Cocoa because Cocoa provides very rich
framework features to mitigate or avoid needing to explicitly use
multiple-threads in application code.
I don't see that. If you need to code a parallel algorithm, Cocoa
provides thread tools, but few pre-coded parallel algorithms.
It does, however, use threads to improve performance, especially in
UI animations and HTML display.
I identified Cocoa features and provided links to them. Cocoa need
multiple-threads in application code less that many other frameworks.
Far be it from me to speak in absolutes. The comments to the
effect that people should use the right tool for the job are
certainly correct. I am advocating using the multiple processes
tool in many cases that I suspect others select the multiple
threads tool.
As it turns out, I have done a lot of multi-threaded programming
for real-time systems using a variety of languages and frameworks.
I would go so far as to claim to be an expert on Posix threads and
related Posix features.
Multiple threads are readily prone to corrupting memory any time
the multiple threads share data structures in memory. Apple
provides excellent documentation on the subject: http://
developer.apple.com/documentation/Cocoa/Conceptual/Multithreading/
articles/ThreadSafety.html
Now, you and I know that if multiple threads are going to read or
modify data with non-atomic operations, that data must be protected
my mutual exclusion locks or a semaphore or similar construct.
Why ? Without protection the memory used to store the structure
will become corrupted when one thread reads half the structure or
threads stomp on each other's writes, etc. I am sure you are aware
of the issues.
Right away, the complexity of your application has increased. You
need to know correct ways to use mutex locks or similar. You now
need to avoid deadlocks and other potential problems.
How many naive folks in this forum jump into threads without
understanding the issues ? How many Computer Science graduates can
write correct multi threaded code ? My anecdotal observation is
that at most 50% of recent CS graduates even know what a mutex lock
is let alone how to correctly use one.
Any CS graduate who graduated after, say, 2002, who doesn't know
thread-safe programming or is not at least aware of thread safety and
semaphores/mutexes/your favorite mutual exclusion construct here/
either missed a very important class, or should have chosen a school
with a better curriculum.
When I taught as an adjunct instructor of CS, my sophomore operating
system class, which was required of all CS majors, highly emphasized
thread safety and how traditional mutual exclusion constructs work.
For many but not all applications, I think it is best to avoid the
added complexity and "risk" by just using multiple processes
instead of multiple threads.
The fact that Apple and many others successfully apply multiple
threads to solve problems does not mean that multiple threads are
the best solution to all problems. My advice is to leave the multi-
threading to the framework providers and hope they know what they
are doing.
I wholeheartedly disagree. While thread safety might be tough to
debug, so is a memory trash if you've malloc'd memory incorrectly, or
performed a memcpy improperly and scribbled on the heap.
Thread safety isn't rocket science. For most operating systems,
multithreading is easier on the system for parallel processing than
using multiple processes. Most modern kernels have been highly tuned
for scheduling threads on multiple processors. Plus, multiple
processes doesn't necessarily rid you of thread safety. If you use
the fastest method of IPC, shared memory, you have the exact same
multiple exclusion problems as you do with threads. If you don't use
shared memory, then you've taken a huge performance hit for your IPC
and synchronization.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden