Here is process state diagram from Modern Operating Systems. Transition from running to ready happens when the scheduler picks another process.
Here is process state diagram from Operating System Concepts.
What does "Interrupt" mean for transition from running to ready? Is it the same as "the scheduler picks another process" in the above?
Thanks.
There are two ways for a process to transition from the running state to the ready state depending on the OS implements multitasking:
With preemptive multitasking, the OS uses timer interrupts (there is one timer for each core or processor in the system) to regularly interrupt whatever process is currently running. The interrupt handler then invokes the OS scheduler to determine whether to schedule another process or continue running the same process. If the scheduler decided to run another process, then the current process transition from the running state to the ready state.
With cooperative multitasking, the OS does not use interrupts to scheduler processes. Instead, a running process should voluntarily yield control to the scheduler to allow it to schedule another process. So processes do not transition between the running and ready states using interrupts, but only voluntarily.
It seems to me that the figure from the Modern Operating Systems book applies to both multitasking methods while the figure from the Operating System Concepts is specifically about preemptive multitasking. Although by changing the word "interrupt" to something more inclusive like "yield," then the other figure would also apply to cooperative multitasking.
Related
As it relates to process scheduling by the OS: I understand that the scheduler requires a "clock" like device, known as an interval timer, to keep track of the amount of time used by each process and when to switch to a ready process.
My question is - where does the interval timer run? It seems like it needs to be running constantly, parallel to any processes, so that it can always keep track of time, including the amount of time being used by the running process. But as we all know only one thing can run on a CPU at any one time, and if the process is running, it means the interval timer cannot run. So therefore, is the interval timer implemented in hardware rather than software? And if so, if I was building a custom OS and scheduler, how would I access and communicate with it in my custom scheduler code?
The "interval timer" as you call it is a hardware timer. It generates an interrupt at a fixed period. When the "RTOS tick" interrupt occurs, the tick handler (typically):
increments the tick counter,
updates any running software timers,
if a task delay or software timer expires, any task blocked on that becomes ready,
the scheduler is run, the highest priority ready task runs.
Note that this is not the only time the scheduler runs. For example scheduling occurs whenever a task explicitly suspends on a delay, timer, semaphore, mutex, event flag, or mailbox for example. Any RTOS call that causes the running task to block/wait causes the scheduler to run.
And if so, if I was building a custom OS and scheduler, how would I access and communicate with it in my custom scheduler code?
You would simply configure the hardware timer to generate the tick interrupt and proceed as above. You might take a look at an existing open-source RTOS to see how it is done. Although FreeRTOS which you tagged is not exactly conventional, uC/OS-II may be a better starting point - it is deliberately simple and was originally implemented to teach RTOS design and implementation. The associate book describing the kernel is freely available in PDF form at https://weston-embedded.com/micrium-books.
If I have a non-RTOS single core system, can one task, say taskA interrupt another task, say taskB, where neither taskA or taskB are interrupt routines? Or is interruption of one task by another only possible through ISR(interrupt service routines) on non-RTOS systems?
For your system to have more than one non-ISR thread implies that there is some sort of multi-tasking - and multi-tasking is not exclusive to an RTOS. One task "interrupting" another is known as preemption. Preemption requires a preemptive scheduler, while an RTOS is necessarily a pre-emptive scheduler, so also are Windows and Linux for example - but these are not real-time since scheduling and preemption is not deterministic.
Preemptive multi-tasking is necessary to support preemption, but real-time deterministic scheduling is not required. Preemption however is not necessary to multi-tasking; some systems (Notably 16 bit versions of Windows prior to Win95, and MacOS prior to OSX) are cooperative multitasking systems where a running task must yield the CPU to allow other tasks to run.
In a preemptive multitasking system, the scheduler executes on exit from the interrupt context and whenever a task invokes a schedulable event (such as giving a semaphore, queuing a message or releasing a mutex. If when the scheduler runs a task becomes ready to run and the scheduling policy requires or allows it to preempt the current task, a context switch will occur.
So in short one non-ISR thread or process "interrupting" another requires an OS that supports preemption, which need not be an RTOS.
Control must be given to the task scheduler in order for a context switch to occur. That can happen as a result of an interrupt if the interrupt handler is designed to call the scheduler. Or it can happen as a result of some function call (such as yield, post, or pend) if that function calls the scheduler.
This task scheduler could be part of an RTOS. Or maybe it's some minimal task switching kernel that you don't consider to be an RTOS . Regardless, some sort of scheduler must get control in order to perform a task context switch.
I had this question in mind from long time and may sound little vacuous. We know that operating system is responsible for handling memory allocation, process management etc. CPU can perform only one task at a time(assuming it to be single core). Suppose an operating system has allocated a CPU cycle to some user initiated process and CPU is executing that. Now where is operating system running? If some other process is using the CPU, then, is operating system not running for that moment? as OS itself must need CPU to run. If in case OS is not running, then who is handling process management, device management etc for that period?
The question is mixing up who's in control of the memory and who's in control of the CPU. The wording “running” is imprecise: on a single CPU, a single task is running at any given time in the sense that the processor is executing its instructions; but many tasks are executing in the sense that their state is stored in memory and their execution can resume at any time.
While a process is executing on the CPU, the kernel is not executing. Its state is saved in memory. The execution of the kernel can resume:
if the process code makes a jump into kernel code — this is called a system call.
if an interrupt occurs.
If the operating system provides preemptive multitasking, it will schedule an interrupt to happen after an interval of time (called a time slice). On a non-preemptive operating system, the process will run forever if it doesn't yield the CPU. See What mechanisms prevent a process from taking over the processor forever? for an explanation of how preemption works.
Tasks such as process management and device management are triggered by some event. If the event is a request by the process, the request will take the form of a system call, which executes kernel code. If the event is triggered from hardware, it will take the form of an interrupt, which executes kernel code.
(Note: in this answer, I use “CPU” and “processor” synonymously, to mean a single execution thread: a single core, or whatever the hardware architecture is.)
The OS kernel does nothing at all until it is entered via an interrupt. It may be entered because of a hardware interrupt that causes a driver to run and the driver chooses to exit via the OS, or a running thread may make a syscall interrupt.
Unless an interrupt occurs, the OS kernel does nothing at all. It does not need to do anything.
Edit:
DMA is, (usually), used for bulk I/O and is handled by a hardware subsystem that handles requests issued by a system call, (software interrupt). When a DMA operation is complete, the DMA hardware raises a hardware interrupt, so running a driver that can further signal the OS of the completion, maybe changing the set of running threads, so DMA is managed by interrupts.
A new process/thread can only be loaded by an existing thread that has issued a system call, (software interrupt), and so new processes are initiated by interrupts.
It's interrupts, all the way down :)
It depends on which type of CPU Scheduling you are using : (in case of single core)
if your process is executing with preemptive scheduling then you can interrupt the process in between for some time duration and you can use the CPU for some other Process or O.S. but in case of Non-Preemptive Scheduling process is not going to yield the CPU before completing there execution.
In case of single Core, if there is a single process then it will execute with given instruction and if there are multiple process then states stored in the PCB. which make process queue and execute one after another, if no interrupts occur.
PCB is responsible for any process management.
when a process initialize it calls to Library function that's System calls and execution of Kernel get invoke if some process get failed during execution or interrupt occur.
I have just received a Microchip PIC32 Ethernet Starter Kit.
I have zero prior experience with PIC devices and would like to know whether PIC32 devices can run multiple processes at the same time?
Yes. One way: you can write a scheduler. A relatively simple way is to set up a timer, and when the timer ticks, you run an interrupt service routine which runs one of your tasks each time through. This is called cooperative multi-tasking, as if any of the tasks overruns the timer tick, the other tasks have to wait for it to complete. If a task crashes, the whole system crashes.
Or you could get an operating system of some sort, for example FreeRTOS has a PIC32 port. This will have scheduling (and inter process communication primitives, and a host of other O/S services) ready made for you.
Depends on what you mean by 'run multiple processes at the same time'.
Microchip PIC32 has only one core, so no, if you interpret 'run' as 'execute code instructions', it is not possible to run the multiple threads of execution that are required to run multiple processes at the same time.
That does not mean you cannot run an OS that supports multiple threads/processes and have them all operate in a useful and harmonious manner. Hardware and software interrupts can effectively change the set of running threads and the OS will run one of them on the one core until the next interrupt, same as on any other uC with a single-core architecture.
I'm doing some fill in the blanks from a sample exam for my class and I was hoping you could double check my terminology.
The various scheduling queues used by the operating system would consist of lists of processes.
Interrupt handling is the technique of periodically checking to see if a condition (such as completion of some requested I/O operation) has been met.
When the CPU is in kernel mode, a running program has access to a restricted set of CPU functionality.
The job of the CPU scheduler is to select a process on the ready queue and change its state.
The CPU normally supports a vector of interrupts so the OS can respond appropriately when some event of interest occurs in the hardware.
Using traps, a device controller can use idle time on the bus to read from or write to main memory.
During a context switch, the state of one process is copied from the CPU and saved, and the state of a different process is restored.
An operating system consists of a kernel and a collection of application programs that run as user processes and either provide OS services to the user or work in the background to keep the computer running smooth.
There are so many terms from our chapters, I am not quite sure if I am using the correct ones.
My thoughts:
1. Processes and/or threads. Jobs and tasks aren't unheard of either. There can be other things. E.g. in MS Windows there are also Deferred Procedure Calls (DPCs) that can be queued.
2. This must be polling.
4. Why CPU scheduler? Why not just scheduler?
6. I'm not sure about traps in the hardware/bus context.