Assuming there is no dependency between the two programs and there are launched on two different processes, there should be no problem even if one of these programs crash. The operating system deals with the resources to allocate for each program (CPU, memory, etc).

By dependencies, I assume you mean no shared memory, not communications between the two of any sort. To guarantee that each runs on a separate core, you could leverage the ability to 'pin' a process to a specific core. Many OSes support this concept, the drawback is that if you allow the system scheduler to start one of the two, you cannot guarantee that you are pinning the second process to the unused core.

I am bit intermediate to Parallel Computing. Can we do a 'pin' in windows...... How can we find weather a core is not under utilization or unused. is there any framework which i can use to schedule a code to a specific Core.

I am agree with Peter Breuer. I just want to add a little remark about the use of different cores on the same processor.

It seems that you want reserve a core for one of your application to obtain the maximal performances, meaning that you want avoid context switch. But, you have also to forbid the utilization of the other cores of your processor. One of the main impact on the performance of an application is the optimization of the cache. If an other application, use a shared level of cache, the performance of your application will be also affected.

My advice is to just launch the two applications. Don't do anything else. From my experience I can tell that pinning processes to specific cores can degrade performance and on a desktop machine almost never increases performance. (This might be different for compute clusters where one MPI process is pinned to a specific core.) The operating system's scheduler is a lot smarter than you are and will find a better strategy than yours. Many times running both codes on the same core some of the time will be faster.

As for your question about exceptions: If you really do run your two applications in separate processes (without one being a child of the other one) there should be no problem if one process throws an exception or even crashes. The operating system should take care of this. There might always be bugs in the OS that crash other processes (or the entire system) if one process crashes. But, usually with exceptions

you are save.

But, you cannot remove all dependence between the two processes. They will always be competing for resources. If you don't pin them to specific cores, they are competing for compute resources (but, as I said before this might still be faster than pinning). And you will never remove the competition for memory resources. If one process uses up the entire memory, no other process (not even the OS) will get any memory.

You don't tell us your operating system or the processor architecture. The implementation in Windows will be different than Linux or Mac. I don't know about Intel, but ARM and AMD and most GPUs have firmware to support it.

There is some open source stuff out there that allows independent threads and processes in multiprocessing. If you are intermediate to multiprocessing, you already know the keywords.

It depends on what level of independence you expect from the two programs. Generally the first answer would be "yes", since the usual level of independence is good for most cases. I.e. if just run on two cores, one program should not crash the other (provided the program and the OS are free of bugs). The ways in which these programms may interact is only relevant if you need very clear guarantees, e.g. real-time behavior or safety-related functions.

In case hard real-time behavior is required for example the question cannot be answered without knowing the exact hardware. You mention that the programs do not use shared resources, but this is close to impossible to realize in realistic hardware. Most times the cores of a multiprocessor share caches or the connection to main memory. So in case one programm accesses the main memory, the other may have to wait for the access to wait for the first program to finish, which can change the execution time. Or the programs may share cache lines which can also influence performance. It would even be possible that one program drives up the heat, so that the OS has to activate a power saving mode for both cores which then again degrades performance for the other program.

The point is, that the concept of two programs sharing no resources is an illusion provided by the OS and the hardware. Some resources will always be shared (and even if it is only because of physical proximity of the cores, making them share a common heat-sink). In most cases however this illusion is performed so well, that one can actually assume independence of the programs. And the cases where one has to look beyond that illusion are rare and require very special methods of development.

@Tilmann Nett is correct. There is always shared hardware. While there is software to run separate processes on each core, there are shared registers, etc on x86 cores. Some multicore ARM SoCs such as TI's OMAP4 and OMAP5 can run completely independent processes even to the point of running independent operating systems. Even then, there is some shared internal bus structure.

"Must not affect in any manner" is highly subjective as already explained by many. If the applications are non-critical (no real time dependency ), running the applications "as is" will be more reasonable than trying really hard to separate the process in memory / CPU cores.

It has to be clear whether the subjectivity is w.r.t. time or w.r.t critical impact of resources to optimise the planning to run with efficient tie-up to resources or to plan with tie-up to cores.

I agree Peter Breuer.

1) open two command-line shell in windows

2) for each shell, launch one application

3) hope this helps

Most of the solutions provided here are really good in fact. But you can also try the following:

First note that the following technique will only work if the codes for both the program are written in same language i.e. C/C++/Fortran.

And the following technique should work properly because this technique is tested for Fortran.

Step 1) Combine the two codes of the program without any dependencies (wrt data).

For example create a main function and call the two separate functions independently.

Step 2) But here use the parallelism concept of OpenMP (http://gcc.gnu.org/wiki/openmp) /*Using OpenMP instead MPI because it is easier to implement than MPI*/

So using OpenMP parallelise the call for each function (i mean the separate code/program).

Step 3) Then use CPU affinity to pin processes (in this case each program) to each core of the dual-core processor.

If possible add timers in each function (or program in your case) and a timer at the end of main.

Notice the time taken in parallel execution. Compare this with individual execution.

/*By hunch, I guess, the individual execution will be faster than the parallel execution because when run individually 2 cores work on each process whereas when you execute two processes parallel, each process is bound to only one core according to the aforementioned method.*/

/*But if you add up the individual running time for each program, then it may be slower than the parallel execution. At least in parallel execution you are utilising both the cores of the processor and if your execution is correct then there should be no core which is idle. Thus this technique will depend on the way you parallelise your program using OpenMP*/ (You can also try MPI instead that will be much more efficient in your case because there is no dependency of each program on one another, but it is harder than OpenMP to implement)

All the Best. Do post your result after you execute the programs parallely.

The most easy way to do it is:

Install a "virtualization system" that let you specify the resources it uses (e.g. VmWare, by the are others that support that features); then create a virtual machine and specify thant it needs a "core" to it, repeat creating another one and other processor core to it. Moreover, if one of the VM crashes the other will keep running.

OpenMP.

Put one block of code under one "#pragma omp section" and second one in another. Both sections inside "#pragma omp sectionS". They will compute on separate cores. In my opinion it's the simplest possible solution. Add #include and add linker option and you're done.

If the code does not need to be portable, you can utilize OpenMP and hardcode an if-else statement based on thread id. Depending on the execution of the algorithm, this may not be the most efficient (even when free of race conditions as you have described) due to cache pressures on the processor.

I can think of two things you can do in your experiment.

First, if you're using Linux you can set the Processor Affinity of each task to a specific CPU (that is, telling the OS to run the task in a specific CPU and nowhere else) using sched_setaffinity().

So if you create your two tasks and set their affinity to different CPUs, you will force the system to run them in different processors, thus minimizing their interaction (depending on the architecture they will affect each other by sharing caches and memory buses, but that's inevitable).

To see how this is used, take a look at:

http://man7.org/linux/man-pages/man2/sched_setaffinity.2.html

And second: That solves the "each task in a different processor" problem, but if you want to minimize interaction with other tasks running in the same CPU as the ones you're interested in (something you will hardly be able to prevent) you can use sched_setscheduler() to change the scheduling policy of your tasks to "realtime" class scheduling (SCHED_RR or SCHED_FIFO). This way they will be prioritized over all other tasks in the system and will always run until they finish.

To see how this works, take a look at:

http://man7.org/linux/man-pages/man2/sched_setscheduler.2.html

I've done this before and will help you a lot in obtaining stable results from each run. Technically, the tasks will only be affected by system interrupts (which will keep on being serviced) but that's all. So try not to touch anything while the tests run, also ;)

Two more things/warnings/caveats:

- If you set the tasks to SCHED_RR or SCHED_FIFO policies and you have only as many cores as you have tasks (i.e. 2 tasks and 2 cores in a dual-core, non-hyperthreaded system), they will use EVERY CPU CYCLE of your system until they finish and no other tasks (not even system tasks) will be allowed to run; the effect being that your system will seem to have locked hard, not even responding to mouse or keyboard inputs. THAT IS NORMAL, and you'll get your system back once they finish running.

- Be careful selecting CPU affinity with Hyperthreaded multicore CPUs. A dual-core HT CPU will look as if it's got 4 cores, but it doesn't; it's got 2 cores, each capable of running 2 threads (thus, hyperthreaded) that look like 2x2=4 logical cores. If you select 2 logical cores sharing the same physical core, the tasks will share a lot of CPU resources, thus giving much slower results than if you select 2 logical cores from 2 different physical cores. I don't know how logical cores are numbered in Linux, but I guess a bit of testing and trying will tell you.

I hope that helps.

P.S. It doesn't say anything in the man pages I linked above, but some of the system calls I mentioned require that the tasks are launched by the superuser (root) or otherwise they will fail silently. At the very least this is true for sched_setscheduler().

Tools like PVM allow you to write separaterograms on separate machines.

If you wnt to run different processes on different processors on different processors use MPI. These methods work for any machine.