This is a theoretical operating systems question:
In which occasions can a process go from the READY state directly to the TERMINATED state without passing through RUNNING?
Is this just happening when the process is killed while being in READY state?
Let there is a parent process which have 3 child process. If parent process is processing and after some time, it abort then the child process will gone from ready to terminated state.
Related
I'm working on getting Redis to run on Solaris 10 and there's a few integration tests that are failing. The test I'm looking into works like this:
Start Redis
It forks and the child starts dumping the database to a backup file (RDB)
There's actually a parent / child / grandchild relationship going on where the grandchild becomes a zombie, but I noticed that only minutes before I had to head home.
After a short time the test script sends SIGTERM to the child
The child catches the signal & shuts down gracefully
The parent calls wait3()
In spite of the wait3() call the child ends up in a zombie state.
The test fails around 90% of the time when I run it. Once it gets into a failed state it never recovers. I tried changing the test to wait significantly longer and although it appears to call wait3() many times after the process has exited, it stays in that state until the parent process(es) are killed.
Unfortunately I won't be able to work on this again until next week, so I'm researching it from home. Most of my googling has only turned up documentation or "why do processes become zombies?" type questions.
This google groups thread from the mid 90s may help, though they're mostly talking about older releases of Solaris / SunOS.
I was mistaken. It looks like the master node doesn't see that its child failed so doesn't wait.
I was going through the Process States. The first state was "Creating Process". What do we mean by creating the process? Is it the completion the program and saving into the hard disk?
The state 'Creating Process' is what you refer to before it goes into a ready state, that is ready to be scheduled by the OS. The process creation state refers to the initial setup of the essentials of a process. In UNIX, at system boot, the first user level process is created called 'init' which is the parent of all the other processes.
UNIX fork() is used to create a new process. During this process creation, the fork() will create a new address space for the child process, a process id (pid) will be assigned, all the mapping of the parent process will be copied into the child's address space and the new program will be loaded in to the child process's address space. This is what happens in 'Process Creation' and once fork() it is followed by a exec() call which will allow the child to run its own program.
I have a question about the following diagram from Operating Systems Concepts: http://unboltingbinary.in/wp-content/uploads/2015/04/image028.jpg
This diagram seems to imply that after every I/O operation, the process is placed back on the ready queue before being sent to the CPU again. However, is it possible for a process to terminate after I/O but before being sent to the ready queue?
Suppose we have a program that computes a number and then writes it to storage. In this case, does the process really need to return to the CPU after the I/O operation? It seems to me that the process should be allowed to terminate right after I/O. That way, there would be no need for a context switch.
Once one process has successfully executed a termination request on another, the threads of the terminated process should never run again, no matter what state they were in - blocked on I/O, blocked on inter-thread comms, running on a core, sleeping, whatever - they all must be stopped immediately if running and all be put in a state where they will never run again.
Anything else would be a security issue - terminated threads should not be given execution at all, (else it may not be possible to terminate the process).
Process termination requires the cpu. Changes to kernel mode structures on process exit, returning memory resources, etc. all require the cpu.
A process simply just does not evaporate. The term you want here is process rundown - I think.
Supposed that we have a runnning process in Linux system, the state of that process will be TASK_RUNNING, after that if It receive the SIGSTOP signal , the process's state will change to TASK_STOPPED.
So I wonder if that process is still in the Running queue?, does the kernel put it to somewhere after change the state from TASK_RUNNING into TASK_STOPPED?
Thanks in advanced.
As OS concepts book illustrate this section "Process States":
Process has defined states: new, ready, running, waiting and terminated.
I have conflict between new and ready states, I know that in ready state the process is allocated in memory and all resources needed at creation time is allocated but it is only waiting for CPU time (scheduling).
But what is the new state? what is the previous stage before allocating it in memory?
All the tasks that the OS has to perform cannot be allocated memory immediately after the task is submitted to the OS. So they have to remain in the new state. The decision as to when they move to the ready state is taken by the Long term scheduler. More info about long term scheduler here http://en.wikipedia.org/wiki/Scheduling_(computing)#Long-term_scheduling
To be more precise,the new state is for those processes which are just being created.These haven't been created fully and are in it's growing stage.
Whereas,the ready state means that the process created which is stored in PCB(Process Control Block) has got all the resources which it required for execution,but CPU is not running that process' instructions,
I am giving you a simple example :-
Say, you are having 2 processes.Process A is syncing your data over cloud storage and Process B is printing other data.
So,in case process B is getting created to be stored in PCB,the other
process,Process A has been already created and is not getting the
chance to run because CPU hasn't called these instructions of Process
A.But,Process B requires printer to be found and other drivers to be
checked.It must also check for verification of pages to be printed!
So,here Process A has been created and is waiting for
CPU-time---hence,in ready state. Whereas,Process B is waiting for
printer to be initialised and files to be examined to be
printed--->Hence,in new state(That means these processes haven't been
successfully added into PCB).
One more thing to guide you isFor each process there is a Process Control Block, PCB, which stores the process-specific information.
I hope it clears your doubt.Feel free to comment whatever you don't understand...