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: Shawn Erickson <email@hidden>
- Date: Wed, 06 Sep 2006 20:06:19 -0700
On Sep 6, 2006, at 6: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 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.
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.
I don't buy into the premise that using a separate process avoids
these issues... it sure doesn't help as much as you seem to believe.
(I have a long history with various approaches to these types of
issues, so I am speaking from experience.)
The cases that can be trivially packaged into a separate process are
also the ones that can be trivially spun off into a secondary thread
with little risk. Basically if you can easily package it in a process
that means you aren't sharing data, sharing state and have minimal
interlock, in other words the operation is basically mostly
independent of anything else going on in your application. This type
of situation is easily also tackled using threading and by using
threading for these you will almost always gain greater efficiency
and easier integration with the rest of your application (trivial to
post status updates back to the UI, etc.).
The cases that are difficult to thread are difficult because the have
some amount data sharing, state sharing, or interlock that must take
place between threads. These types of situations are also more
complex to package into separate processes (often with the cost of
overhead above what would be needed in the trivial case and with
similar issues you would face if you used threads). So you really
don't gain much in doing so (but it doesn't mean it might not make
sense to do so)... Cocoa provides good tools that help with these
issues if you use threads or processes (some would be the same for
both).
In either situation if you have a memory/heap smasher in your code
you will cause problems for either the single process or one of the
secondary processes... you have a bug to fix, memory isolation wont
fix it.
Now in many situations using secondary processes makes sense
(especially if a prepackaged process already exist for that task you
need done) and can be a more resilient solution (with some extra
work). One obvious example is to allow a large virtual memory pool to
exist for the worker process.
Anyway as I said before evaluate your needs and pick the right tool
for the task at hand... also do revaluate your decisions down the
road as you gain experience and the environment changes (Cocoa is
being enhanced in 10.5 in this space).
So my message to folks on this list is don't fear threading (or use
of multiple processes) but do take the time to learn the concepts,
issues and tools available to you. If you are not comfortable with
threading get comfortable with it (countless resources exist to help
with that)... threading is going to get more and more prevalent in
every day programming (luckily also frameworks will continue to do
more of the work for you).
-Shawn _______________________________________________
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