+1 vote
135 views

Consider a process P1 that is executing on a Linux-like OS on a single core system. When P1 is executing, a disk interrupt occurs, causing P1 to go to kernel mode to service that interrupt. The interrupt delivers all the disk blocks that unblock a process P2 (which blocked earlier on the disk read). The interrupt service routine has completed execution fully, and the OS is just about to return back to the user mode of Pl. At this point in time, what are the states (ready/running/blocked) of processes P1 and P2 ?

2. P1 is ready and P2 is running
3. P1 is running and P2 is ready
4. P1 is blocked and P2 is ready

| 135 views
0
I think its 2.

Because once P1 neutralizes the interrupt, it would go to ready state. And since P2 was blocked, after resolution of interrupt it would again be running.
0
I also marked it as 4 but it is given as 3... shouldnt it be that P1 is blocked as the OS is just about to return the commads to the user and it hasnt returned it yet .. So how can P1 be runnning?????
0
Can you share the explanation?
0

Explanation:

During this process P1 was always running, but CPU was executing kernel

code, to process the interrupt. P1 is never swapped or blocked. P1 is in

running and P2 is in ready queue.

0
But according to question, P2 is blocked right? I m not understanding how its in ready queue.
0

$p_1$ gets unblocked so In ready queue.

Going to blocked state depends on the process ( unless a blocking system call ), so $p_1$ remains in the running state during I/O completion.

Ref : here

correct me if I'm wrong

0

The interrupt service routine has completed execution fully, and the OS is just about to return back to the user mode of P1

how P1 is running? they also mentioned that OS is about to return back to the user mode of P1.

0

i doubt P1 was is running state

0
$P_1$ never left the running queue.
0

hows that possible?

Process moved to blocked state does not imply that it is preempted. Preemption is when a process is moved back to the Ready Queue from the Running State against its will.

0
0
0

Among all the 5 state through which a process goes , BLOCK state is the only state where the process goes by its will .while in other it depends upon the Scheduler .. And The scheduler we have seen are care about CPU bound process , and not for I/o bound process .

+1
so does that mean that when interrupt came P1 was not blocked at the first place?
0
yes I think so, just switched to kernel mode where it can't do anything, but nobody moved it to the blocking queue, ready queue and it didn't go on its own.
0

can you provide some standard resource which contain detailed explanation about the same?

0
okay so that means if a system call or an interrupt occurs due to which the mode changes from user to kernel what ever is there in the user mode will stay there only only the mode will change ...
0

This could be a good read here here(page 9)

Apologies for the mistake in this question.

The question mentions that  while P1 is executing, the data from the disk arrives and the interrupt gets serviced by process P1.

I think question is wrongly formulated as it should be:
1. P1 is executing
2. Disk interrupt occurs.
3. Interrupt is serviced by the ISR after the completion of currently running instruction cycle by the CPU.

After every instruction cycle the processor will check for interrupts to be processed if there is no interrupt is present in the system it will go for the next instruction cycle which is given by the instruction register.

If there is an interrupt present then it will trigger the interrupt handler(ISR), the handler will stop the present instruction which is processing and save its configuration in a register and load the program counter of the interrupt from a location which is given by the interrupt vector table. After processing the interrupt by the processor interrupt handler will load the instruction and its configuration from the saved register, process will start its processing where it’s left. This saving the old instruction processing configuration and loading the new interrupt configuration is also called as context switching.

Thus process P1 doesn't service the interrupt as mentioned by the question.

by Junior (659 points)

+1 vote
1
2
3