Multiple application domains and multiple processes

Multiple application domains and multiple processes

• elfw

  You should not use multiple application domains for your components unless you need the security and isolation provided by application domains.  In order to share objects across app domains they will have to be marshalled and therefore must derive from MarshalByRefObject.  Marshaling is very expensive compared to a direct call so ultimately your app will run slower. Your design goal then would be to minimize the amount of cross-domain calls being made.
  
  Personally I think you should run all your components in the same app domain unless you are trying to load add-ins.  In this case you may want to put all your add-ins in a separate app domain so that way they are secure and isolated.  However all your core components should run in the same domain.
  
  Multiple processes are only useful when each logical process is useful (and executable) by itself.  The only real benefit is that you can run each process separately if you need to.  However cross-process communication requires LPC or RPC and therefore is really not recommended for most cases.
  
  I think you are confusing processes with processors.  OpenMP (guess you're using C++) is a multithreaded library.  Whether those threads are in the same process or app domain or separate is irrelevant.  Windows doesn't schedule processes it only schedules threads.  The purpose of a process is to group threads together.  Windows itself doesn't do anything, scheduler wise, with a process.  So it seems like you just want to make your app multithreaded.  This is easily done in a single process or app domain by using either the thread pool or worker threads (using Thread class).  By using threads (or the OpenMP library) your application will run across whatever processors are available on the machine.  Windows will actually put a thread on one of the free processors.  Subsequently when Windows needs to run the thread again it'll try for the same processor (for caching and performance reasons) but if it can't it'll just move it to another processor.  All this is invisible to you. 
  
  Personally if you are using .NET then you should be using the Thread class and the thread pool instead of OpenMP.  OpenMP is more for native C++ apps that don't want to target the Win32 threading API directly.  .NET already provides this functionality for you.
  
  So in a nutshell I would use a single app domain in a single process.  I would use the thread pool and Thread instances whereever I need to do asynchronous work or to listen for background events (like from a device or something).  Then Windows will deal with the rest of it.  Windows will have no problem using the processors available on the machine.
  
  For more information on Thread and the thread pool you should look in MSDN because it is a complex topic.  You should also search the forums because I remember reading a question of recent about when to use each.  Good luck.
  
  Michael Taylor - 10/29/05
  
  

• windthorstking

  TaylorMichaelL wrote:

  I think you are confusing processes with processors.  OpenMP (guess you're using C++) is a multithreaded library.  Whether those threads are in the same process or app domain or separate is irrelevant.  Windows doesn't schedule processes it only schedules threads.  The purpose of a process is to group threads together.  Windows itself doesn't do anything, scheduler wise, with a process.  So it seems like you just want to make your app multithreaded.  This is easily done in a single process or app domain by using either the thread pool or worker threads (using Thread class).  By using threads (or the OpenMP library) your application will run across whatever processors are available on the machine.  Windows will actually put a thread on one of the free processors.  Subsequently when Windows needs to run the thread again it'll try for the same processor (for caching and performance reasons) but if it can't it'll just move it to another processor.  All this is invisible to you.

  
  An application that uses OpenMP must only be used in a single application domain program. If another application domain is loaded into a process with the OpenMP runtime already loaded, the application may abort.
  
  

  TaylorMichaelL wrote:

  Personally if you are using .NET then you should be using the Thread class and the thread pool instead of OpenMP.  OpenMP is more for native C++ apps that don't want to target the Win32 threading API directly.  .NET already provides this functionality for you.

  
  OpenMP gives more than what the threading library of the Win32 API or the Thread class of the .NET. OpenMP automatically creates threads for you to make the optimum use of the multiple processors in the machine running the code.
  look at this sample code:
  

  #pragma omp parallel { #pragma omp for for(int k = 1; k < 100; ++k) x[k] = (y[k-1] + y[k+1])/2; }

  If  this code is running on a 2 processor machine, then two threads will be created to execute this code. The first thread will be allocated for the first 50 iterations, and the second for the second 50 iterations.
  If this code is running on a four processor machine, then four threads will be created to execute this code, each thread handles 25 iteraions of the loop.
  This automated thread handling is much more than what the .NET thread class gives or the Win32 API.
  
  My application is a server application that would serve multiple clients. I want to separate the execution of each request for multiple clients, that's way I need a code separation strategy, either using multiple processes or multiple domains in one process. And in both cases (either using multiple application domains or multiple process), I need the application to make the best use of the processors on the machine. Many copies of the server application would be running on different machines, so I don't know the exact number or processors. That is why I need to use OpenMP.
  
  Any Ideas

  
  
  

• omelete

  Thanks for your reply.
  As far as I understand, using multiple application domains is better in terms of performance and usage of system resources. So why would I need to use multiple processes Should I always use application domains as the code separating unit
  
  I am trying to build a small application that contains multiple components. I am still in the design phase. I am thinking of using OpenMP library, but OpenMP doesn't allow for multiple application domains, So if I use OpenMP, I will use multiple processes to separate code. OpenMP would allow me to build multithreaded application easily ( the applicatoin would run on multiple processor machines, so I want to make use of the processors).On the other hand, I don't want to loose the ability to use multiple application domains as a way of increasing performance and decreasing resources usage.
  
  Any help would be appreciated.
  
  
  

• Ray987

  Application domains are logical processes in .NET.  Short of remoting you can't communicate between app domains.  You should use app domains when you need logical isolation of components within your application due to security or trust issues.  For example many applications use a separate app domain for addins because addins can't be trusted.  Everything in a single process should work together to perform a task or group of tasks.  You should not, for example, create an app domain for your UI and a separate app domain for your database code.
  
  You should use a separate process when the processes can stand alone and don't necessarily need each other to work properly.  For example the compiler is a separate process from the IDE.  The IDE can run without ever using the compiler and the compiler can run outside the IDE.  Using app domains doesn't make sense here because you couldn't run the compiler without also loading the IDE.  Note however that the IDE could, instead of spawning the compiler process, load the necessary compiler components in a separate app domain if it chose to do so but this would mandate that the compiler executable be built such that the core compiler functionality is accessible through a shared library that could be loaded into an app domain independent of the compiler process.
  
  Perhaps if you could provide us with a more concrete example of what you are trying to accomplish we might be able to provide you better guidance on the best options.
  
  Michael Taylor - 10/28/05
  
  
• Multiple application domains and multiple processes