0

This question was a part of my Mid-Sememter Exams, and its answer as given by the prof is quite absurd.

I just want to know what is correct answer.

CODE:

#include<unistd.h>

  // Other Libraries  


void ChildProc()  
{  
  sleep(10);
  printf("Child Process\n");
}

void ParentProc()
{  
  printf("Parent Process");
}  

int main()  
{  
  pid_t pid;  
  pid = fork();  

  if(pid==0)  
    ChildProc();  
  else  
    ParentProc();  

  return 0;  
}

QUESTION: What are all the possible outputs of the following code?

My answers were,

1)
OUTPUT: None
REASON: When the fork fails.(System does not allow creation of a child process)

2)
OUTPUT: Parent Process
REASON: As both parent and child are now in race condition. Who ever may execute first, the parent finishes early and thus would exit the function, and then the program itself will exit. Now the child can't stay alive when the parent ended. Thus it also ends.

But the prof considered another state, when the child starts execution first and starts the sleep loop. Now on the parent's turn, the processor is too busy and thus keeps the process in pending state for ~10seconds. Now by this time the child completes the sleep and resumes execution, and gradually parent executes and thus the output is,

OUTPUT:
Child Process
Parent Process

Though probability of this happening is very very very rare, and only when the process context switcher is very busy but still he says it is possible? Now i am not convinced with his reasoning, and what to know is it really possible, at least in now-a-days linux OS ??

Filburt
  • 17,626
  • 12
  • 64
  • 115
Pinkesh Badjatiya
  • 346
  • 1
  • 5
  • 15

4 Answers4

2

It is in theory POSSIBLE that the parent process is blocked for 10 seconds [not by the CPU as such, but by the OS scheduling mechanism]. But since the forked process is at the same priority as the parent in this case, it's quite unlikely that the child process gets to run before the parent completes, but like any two unsynchronized processes, it's impossible to entirely guarantee which order they execute in.

On my machine, certainly, the child process doesn't run until well after the parent process has completed. So output is:

Parent process 
[my prompt $] Child Process

Every time. But it's not absolutely 100% guaranteed to happen that way.

Mats Petersson
  • 126,704
  • 14
  • 140
  • 227
  • I have a similar opinion, but the fact that the process remains in blocked state for 10sec before execution is practically impossible. My argument is, in theory its possible but practically impossible. – Pinkesh Badjatiya Sep 12 '15 at 20:44
  • Agreed. It would require some pretty extraordinary circumstances. Something like another process starting that has MUCH higher priority at the exact moment when the child process starts. But even then, reversing the order is highly unlikely. – Mats Petersson Sep 13 '15 at 07:00
  • agree absolutely, but the question is "IS IT **POSSIBLE** ?" – Pinkesh Badjatiya Sep 14 '15 at 21:27
  • Yes, and it is. Actually, I have seen situations where Linux does really weird stuff with process timing if data is swapped to disk. It can take half a minute to switch between one application and another. So in that situation, it MAY happen that a process is held for 10 or more seconds. – Mats Petersson Sep 14 '15 at 21:37
0

Refer to another question from '11:

understanding fork(), sleep() and processes flux

The parent process should use wait() or else I believe it would only show:

Parent Process

Child Process

(or fail to fork)

Community
  • 1
  • 1
Wyllow Wulf
  • 410
  • 4
  • 23
  • Calling wait makes the parent explicitly wait for the child to execute, till then it just literally waits. This corrects the above code. Rather we have to find the output of this wrong code. :P – Pinkesh Badjatiya Sep 10 '15 at 18:28
0

We cannot predict which process is gonna run first but yes if a process is in sleep state the other process gets the CPU time quantum.

O/P : parent process child process

Rohan Nagalkar
  • 433
  • 2
  • 5
  • 15
0

I think you have not accurately phrased the words of your professor. That can be likely to happen in old machines but not in modern machines. You can not predict whether child will execute before parent or vice versa due to multitasking multi-thread nature of systems. IN GENERAL, if child goes on sleep it is not necessary that parent wait due to child sleep but in your case parent can have to wait to collect exit status from child after printing its statement(in case child run first).

Note:

when I run your code it first run parent(prints parent process), gives back my console then run child( print "childprocess") and then goes to continuous wait :)

when I put printf("main process") at the end of main() before return 0; it prints as in following order parent process, main process, comeback to console, (sleep), child process, main process. One thing is clear that parent will not wait for child and it is not necessary that child will always get cpu before parent.

QUESTION: why program goes in continuous wait and why execute statements which are outside of parent and child, two times

incompetent
  • 1,715
  • 18
  • 29
  • btw he knows quite well about the kernel has been clearing my concepts from day 1. Your reason is quite unlikely to happen. – Pinkesh Badjatiya Sep 12 '15 at 20:46
  • oh i did not mean to say he does not know I try to emphasize that if you have rightly phrased what he said then he may be right for old machines not modern ones i try to rephrase my answer – incompetent Sep 13 '15 at 07:48
  • Regarding the last question that you asked, I am not sure what is your actual question. But from my guess you want to know why are global initialisations done twice. Actually, the globals are initialised only once, and when a child is forked than the variables are copied(actually child has shared memory with parent, untill it writes something, know as copy on write policy). – Pinkesh Badjatiya Sep 14 '15 at 21:54