Making sure two processes interleave

In a C program on Linux, I fork() followed by execve() twice to create two processes running two seperate programs. How do I make sure that the execution of the two child processes interleave? Thanks Tried to do the above task as an answer given below had suggested but seems on encountering sched_scheduler() process hangs. Including code below...replay1 and replay2 are two prograns which simply prints "Replay1" and "Replay2" respectively.

# include<stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <signal.h>
#include <sched.h>


void main()
{
 int i,pid[5],pidparent,new=0;
 char *newargv1[] = {"./replay1",NULL};
 char *newargv2[] = {"./replay2",NULL};
 char *newenviron[] = {NULL};
 struct sched_param mysched;
 mysched.sched_priority = 1;
 sched_setscheduler(0,SCHED_FIFO, &mysched);  
 pidparent =getpid();

 for(i=0;i<2;i++)
 {
   if(getpid()==pidparent)
   {
    pid[i] = fork();
    if(pid[i] != 0)
    kill(pid[i],SIGST开发者_如何学COP);
    if(i==0 && pid[i]==0)
     execve(newargv1[0], newargv1, newenviron);
    if (i==1 && pid[i]==0)
     execve(newargv2[0], newargv2, newenviron);       
   }
 }
for(i=0;i<10;i++)
 {
   if(new==0)
    new=1;
   else
    new=0;
   kill(pid[new],SIGCONT);
   sleep(100);
   kill(pid[new], SIGSTOP);
 }


}

---

Since you need random interleaving, here's a horrible hack to do it:

• Immediately after forking, send a SIGSTOP to each application.
• Set your parent application to have real-time priority with sched_setscheduler. This will allow you to have more fine-grained timers.
• Send a SIGCONT to one of the child processes.
• Loop: Wait a random, short time. Send a SIGSTOP to the currently-running application, and a SIGCONT to the other. Repeat.

This will help force execution to interleave. It will also make things quite slow. You may also want to try using sched_setaffinity to assign each process to a different CPU (if you have a dual-core or hyperthreaded CPU) - this will cause them to effectively run simultaneously, modulo wait times for I/O. I/O wait times (which could cause them to wait for the hard disk, at which point they're likely to wake up sequentially and thus not interleave) can be avoided by making sure whatever data they're manipulating is on a ramdisk (on linux, use tmpfs).

If this is too coarse-grained for you, you can use ptrace's PTRACE_SINGLESTEP operation to step one CPU operation at a time, interleaving as you see fit.

---

As this is for testing purposes, you could place sched_yield(); calls after every line of code in the child processes.

---

Another potential idea is to have a parent process ptrace() the child processes, and use PTRACE_SINGLESTEP to interleave the two process's execution on an instruction-by-instruction basis.

---

if you need to synchronize them and they are your own processes, use semaphores. If you do not have access to the source, then there is no way to synchronize them.

---

If your aim is to do concurrency testing, I know of only two techniques:

• Test exact scenarios using synchronization. For example, process 1 opens a connection and executes a query, then process 2 comes in and executes a query, then process1 gets active again and gets the results, etc. You do this with synchronization techniques mentioned by others. However, getting good test scenarios is very difficult. I have rarely used this method in the past.

• In random you trust: fire up a high number of test processes that execute a long running test suite. I used this method for both multithreading and multiprocess testing (my case was testing device driver access from multiple processes without blue screening out). Usually you want to make the number of processes and number of iterations of the test suite per process configurable so that you can either do a quick pass or do a longer test before a release (running this kind of test with 10 processes for 10-12 hours was not uncommon for us). A usual run for this sort of testing is measured in hours. You just fire up the processes, let them run for a few hours, and hope that they will catch all the timing windows. The interleaving is usually handled by the OS, so you don't really need to worry about it in the test processes.

---

Job control is much simpler with the Bash instead of C. Try this:

#! /bin/bash

stop ()
{
    echo "$1 stopping"
    kill -SIGSTOP $2
}

cont ()
{
    echo "$1 continuing"
    kill -SIGCONT $2
}

replay1 ()
{
    while sleep 1 ; do echo "replay 1  running" ; done
}

replay2 ()
{
    while sleep 1 ; do echo "replay  2 running" ; done
}

replay1 &
P1=$!
stop "replay 1" $P1

replay2 &
P2=$!
stop "replay  2" $P2

trap "kill $P1;kill $P2" EXIT

while sleep 1 ; do 
    cont "replay 1 " $P1
    cont "replay  2" $P2
    sleep 3
    stop "replay 1 " $P1
    stop "replay  2" $P2
done

The two processes are running in parallel:

$ ./interleave.sh
replay 1 stopping
replay  2 stopping
replay 1  continuing
replay  2 continuing
replay  2 running
replay 1  running
replay 1  running
replay  2 running
replay 1  stopping
replay  2 stopping
replay 1  continuing
replay  2 continuing
replay 1  running
replay  2 running
replay  2 running
replay 1  running
replay  2 running
replay 1  running
replay 1  stopping
replay  2 stopping
replay 1  continuing
replay  2 continuing
replay 1  running
replay  2 running
replay 1  running
replay  2 running
replay 1  running
replay  2 running
replay 1  stopping
replay  2 stopping
^C