12 apps safer than 1 app with 12 threads?

[Brett]

Let's say some one makes the argument that instead of multi threading an
application, they say it's better just to make multiple applications. The
app does the same thing for different modules. The modules are conceptually
the same. They contain mostly data but some processing to get data. The
app knows nothing about how they get the data. Just that they return data
in a starndard format. The argument is based on 12 apps vs. 1 multi
threaded app. 1 app can crash and leave the others alone. Whereas a multi
threaded app can have one thread crash and bring down the whole thing.

Consider the multi threaded app uses an interface with 12 classes to
encapsulate variability. Most work is done in one main class on the other
side of the interface and makes use of these 12 classes. I say
encapsulating the variability and using the interface is best. As for one
thread bringing down the whole app, there are two places to catch this.
First, if one thread has a problem, it's own error catching should take care
of it. Second, if the problem falls through the child thread, the main
thread can catch it. Of course, if there is a problem in the main thread,
all 12 child threads have an issue since the main thread must run. The
whole thing may stop at this point.

Contrast that with the 12 different applications. If one of the apps have a
problem in the main processing area because it received bad data from its
child class, the other 11 apps keep on going.

My question is, without regards to code maintenance, which clearly the
interface design wins hands down, or other topics, is the 12 app model
better than the multi threaded app that basically puts each app on its own
thread in the same process?

Thanks,
Brett

 

[Marcos Stefanakopolus]

This is probably not the opinion you want to hear, but here goes:

If your reason for desiring to put the 12 threads into 12 separate
applications is for robustness against crashes, then you're basically saying
"Sure I want robustness, but I'm not actually willing to do the work of
checking return codes, handling exceptions, failing gracefully, etc., in my
threads."

If you're going to go ahead and admit that openly and proceed from that
standpoint, then heck yeah, you'd _better_ put everything into separate
applications. Implementing the inter-process communication between the 12
is harder, to be sure, than communicating between threads with simple events
and EventArgs objects, and as one can assume that you're going to be equally
sloppy about implementing the IPC, that's just one more set of bugs you'll
be creating that having stuff in 12 separate processes might (but probably
won't) help you with.

Seriously, though: the simpler of two equally functional strategies is
almost always the better one. If you really need 12 threads for something,
then have 12 threads, but go to the bother of doing it right. After all,
the C# compiler guys went to a lot of trouble to give you an easy "try{ }
catch { } finally { }" idiom to work with exactly so that it's _easy_ to do
the right thing. So just do that and get on with the interesting part of
whatever it is you're implementing. Don't set yourself up for debugging
hell.

 

[Brett]

This is probably not the opinion you want to hear, but here goes:

If your reason for desiring to put the 12 threads into 12 separate
applications is for robustness against crashes, then you're basically
saying "Sure I want robustness, but I'm not actually willing to do the
work of checking return codes, handling exceptions, failing gracefully,
etc., in my threads."

This is good. Basically nail in coffin...silver bullet for the guys arguing
12 apps are better. Thanks.

Brett