Child and parent process execution is parallel and which starts first depends on OS scheduling. But what can be done to start child always before the parent?
This is
Just put wait(0); inside the parent. So parent will wait until child is done.
if(child){
//do whatever
}
if(parent{
wait(0);
// so whatever
}
You can achieve this thing in case of pthread
(POSIX thread), but not in case of process.
See, the process scheduling is always in the hands of kernel and that you cannot manipulate explicitly. In a parallel-processing system all processes (whether it is child process, parent process or other zombie process) all are executed in parallel, that you cannot change.
The sleep()
method could work, but it is very poor approach to be followed.
1. By making use of signal handling.
When you fork()
a new child process, just then you sleep()
or pause()
the parent process. Child process will be executed where as the parent process will be in waiting position. And then child process sends custom signal which will be handeled by parent process to continue the execution.
(This is also hectic, because you need to handle signal in program).
2. By using the system calls.
By making use of system calls you can handle the process state (ready, suspend, terminate, etc). There are certain shell commands that implicitly uses the system-signal-handling to change the process state/priority. If you know the processID (pid) then you can do:
kill -SIGSTOP [pid]
kill -SIGCONT [pid]
And in case of c-programming you can do:
system("kill -SIGSTOP [pid]"); //pause
and
system("kill -SIGCONT [pid]"); //resume
Moreover, if you can you specify the actual problem where you are going to implement this thing, i could suggest you suitably.
I don't really know why people keep telling not to rely on this behaviour, it's actually used a lot in tracing programs (strace, ldtrace, ...).
First, fork your process and get the child pid, stop the child, and resume it in the parent:
pid_t pid = fork();
if (pid == -1)
abort();
else if (pid == 0) {
raise(SIGSTOP); // stop the child
} else {
waitpid(pid, NULL, WUNTRACED); // wait until the child is stopped
kill(pid, SIGCONT); // resume the child
}
In linux if you want the child process run first, you need to use kernel.sched_child_runs_first
sysctl parameter
Use a binary semaphore with initial value 0. After fork, parent should wait on the semaphore. After child starts, it can signal the semaphore (i.e., make it 1). Then, parent's wait would be over and it will progress.
There is no guarantee for one process to be scheduled before another. Even if you put the parent to sleep()
, it could very well happen that the child executes first, if other processes have preempted the parent right after the fork. The child and parent can very well run truly in parallel on two CPUs.
Actually, there is no value in doing so. If some kind of synchronization is required between the two processes, use an explicit mechanism like pipes/signals, etc.
In short: do not write code to rely on behaviour that is not guaranteed.
Threads provide more mechanisms to synchronize parallel code execution. You might have a look at pthread. Note that threads – different from processes – share resources like memory, etc. which may impose other problems.