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: Erik Buck <email@hidden>
- Date: Wed, 6 Sep 2006 21:38:51 -0400
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 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.
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.
_______________________________________________
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