2
$\begingroup$

I'm starting out in an Operating Systems module. I have a few understanding questions to think about, which will not be gone through in class.

A process state model is an abstraction (or model) which is used to explain what can happen to a process. Give a state of the process, it tells you what is the next allowed states and what causes the process to be in that state, and so on. A model is only at a certain level of abstraction. In this question, we will be focusing on the 5-state process model from the lecture.

(a) Is it possible for a process to never go to Terminated state. If so, give 3 possible scenarios when this can occur. If not, explain your reasoning.

(b) Suppose a process is in terminated state. Discuss whether you should be able to check at any time if a process is in terminated state at all times. Are there any implications?

5 state process model

enter image description here

I have attempted to answer all these questions, but because of their theoretical nature, I think there might be a lot more dimensions to these.

a) I think it is not possible for a process to never go to termination, given enough time, because there are multiple ways a kill() or exit() command can be called, depending on their policy and mechanism in the operating system?

b)

I think it is important because a process in termination state still holds some data and requires the OS to do some cleanup. A process might not be running for other reasons other than termination, it could be in a blocked state without any IO activity or just be inside the ready state.

Can someone check my understanding on these questions? Thanks.

| cite | improve this question | |
$\endgroup$
  • $\begingroup$ We discourage "please check whether my answer is correct" questions, as only "yes/no" answers are possible, which won't help you or future visitors. See here and here. Can you edit your post to ask about a specific conceptual issue you're uncertain about? As a rule of thumb, a good conceptual question should be useful even to someone who isn't looking at the problem you happen to be working on. If you just need someone to check your work, you might seek out a friend, classmate, or teacher. $\endgroup$ – D.W.♦ Feb 17 '19 at 20:50
2
$\begingroup$

a) A process does not necessarily have to terminate, it only reaches the terminated state if it exits voluntarily. If a process has no exit statement (e.g. a server), it would never reach the terminated state unless killed by the OS. Other ways for a process to never reach termination include not being scheduled when ready because some other process with higher priority is always scheduled before it (starvation), or being stuck in the blocked state waiting for some resource but never getting it, for example, trying to obtain a lock (deadlock/livelock).

b) If we cannot check wether the process has reached the terminated state or not, we can never free up its resources (stack, data, process table entry). It is important for the OS to be able to tell what state a process is in for the scheduler to work properly. If a child process terminates and reaches the 'Z' state, the operating system needs to have this information when it tries to pick a process to schedule. This prevents processes that no longer need CPU time from being scheduled. If the OS did not have this state information available at all times, the implications would be wasting memory space and CPU time.

I suggest reading up on the wiki for the exit, wait and fork syscalls for better understanding :)

| cite | improve this answer | |
$\endgroup$
  • 1
    $\begingroup$ Hi, can I clarify in Q1, when one does Ctrl C or something to stop the termination of the program, what is actually happening? Is it the user terminating the process or the operating system terminating the process. I don't really know the right jargons here. $\endgroup$ – Prashin Jeevaganth Feb 17 '19 at 13:27
  • $\begingroup$ @PrashinJeevaganth the shell in which the program is running sends the SIGINT signal to the process when CTRL+C is pressed. Two things can happen: (1) the process has a signal handler and catches the SIGINT and decides what it wants to do (typically, exit voluntarily and safely (kill its children), but the process can handle it however it wants). (2) in case of no signal handler, the operating system terminates the process, note that its children will not be killed. $\endgroup$ – Gert Feb 17 '19 at 13:48
  • $\begingroup$ @PrashinJeevaganth basically the user asks the operating system to terminate the process. You could say the user terminated the process, however in this context it would be better to say that the operating system did $\endgroup$ – Gert Feb 17 '19 at 14:04
  • 1
    $\begingroup$ Another question I have that I'm not too sure is does this Termination state refer to natural termination or does killing by some other factor even end up in this state? This would narrow down the scope of the possible answers for the question $\endgroup$ – Prashin Jeevaganth Feb 17 '19 at 14:17
  • $\begingroup$ @PrashinJeevaganth ohh, yes. The termination state is only reached when the process exits voluntarily. When killed by the operating system it is simply removed from the process table and ceases to exist. The deletion of a process in terminated state happens after the parent waits for it. Good catch! I will update my answer to reflect this $\endgroup$ – Gert Feb 17 '19 at 14:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.