Subj : Re: Dual core and Multithreading
To   : comp.programming.threads
From : David Schwartz
Date : Tue Sep 27 2005 03:25 pm


<donotcareaboutspam@googlemail.com> wrote in message 
news:1127854961.757630.108140@g47g2000cwa.googlegroups.com...

> So that dcom server acts as a wrapper for the processing thread, and
> it's usage was justified because another machine could do the
> processing of the library, freeing up cpu resources for the main
> application.

    There are many advantages to using a separate process for a logically 
separate function. One is that a crash in the library won't necessarily 
crash the main program. This is especially true if the 'client' code is 
smart enough to restart the server part of the code and reconnect with it. 
It also helps to eliminate false sharing that can cause a process to run 
less efficiently.

    The advantage of threads is that vm and other resources are easily and 
fully shared. If this is not needed with a particular aspect of your 
program's operation, then being in a thread can be a disadvantage.

> But due to stability issues I'm dropping the networked feature, so that
> I've come down to ask myself if running the library out of proccess on
> the same machine with a dual core or smp adds any advantage over
> running that library thread in the same process of the main
> application. This way I could drop DCOM/COM completely.

    Fix the stability issues.

> So, do you think that an out of process feature is not needed?
>
> That library basically attaches a thread which does heavy audio
> processing and offers an interface to control some parameters of audio
> generation.
>
> So, is it the same to use this libray in the same process or is there
> any advantage to let it work inside an own process which offers a dcom
> interface to the main app?

    There are many advantages. Primarily, isolation. That is, a bug in the 
library that causes it to corrupt memory can't cause unpredictable problems 
in the code using the library. A memory leak in the library won't cause the 
programs using it to grow in size.

> The point is that I once had an smp machine running win2k, and it would
> never spread the workload of a process onto both cpu's, is it possible
> that this was only because it could have been a single threaded app
> which would have spreaded it it was multithreaded?

    A single threaded application can't run application code on more than 
one CPU on current operating systems.

    DS

> Thanks in advance.
>

.