RTOS Scheduling: FCFS, SJF, Priority, RR, Multilevel Queue - Types of Kernel

[vead]

scheduling is process by which operating system decide which one task will be next on processor

scheduling determine the order in which task are executed

different os kernel may use different scheduling algorithm

scheduling algorithm

First Come First Serve (FCFS) Scheduling

Shortest-Job-First (SJF) Scheduling

Priority Scheduling

Round Robin(RR) Scheduling

Multilevel Queue Scheduling

Q1
which scheduling is used in RTOS ?
I think Priority Scheduling but I don't why ?


I have another question about kernel I have read about kernel for RTOS

1)type of kernel

Monolithic kernels
Micro kernel

2)type of kernel

preemptive kernel
non preemptive kernel

I don't understand difference between both type ,

Q which type of kernel may be used in RTOS , I think preemptive kernel, Micro kernel

 

[cpscdave]

So a RTOS is one that needs to accomplish a set of task in real time (ie as soon as possible). The OS will also have a bunch of other tasks that need to be accomplished but the can wait.

so for Q1 priority is correct, but why? Ask yourself why would a RTOS need to ensure that certain processes get executed first?

What is the difference between a microkernel and monolithic?
A monolithic kernel was the first model of an OS that was developed. Developer put everything that the kernel could ever possibly need into kernel space. This carries a bunch of extra overhead. Why would this be bad for a RTOS?
A micro kernel is one where just the bare minimum is included in the kernel, and any additional functionality that is needed needs to be built and run in user space.
Why might this be good for a RTOS?

Preemptive scheduling allows the OS to interrupt an executing process and allow another process to take over. Think about drivers pulling over to the side of the road to allow an emergency vehicle by.
Non preemptive is the opposite. Once an process is allocated some execution time that process is allowed to finish its time before being interrupted.
So which do you think would be better for a RTOS?

 

[nsaspook]

Your questions really don't have a definitive answer as it depends on the task and what runs best in the field vs what's 'best' in CS theory.

Preemptive scheduling for tightly bound event-driven hardware tasks should be used carefully, especially in devices that have limited resources like micro-controllers. As long as the processes are isolated things run smoothly but as soon as they become dependent on each other for resources it becomes a mine-field for bugs so a "super-loop" 'state machine/ISR' run-to-completion (RTC) or Task Switcher kernel approach to real-time is sometimes a better RTOS abstraction.

http://www.barrgroup.com/Embedded-Systems/How-To/Preemption-Perils

http://www.embedded.com/design/prototyping-and-development/4025691/Build-a-Super-Simple-Tasker

 

[vead]

So a RTOS is one that needs to accomplish a set of task in real time (ie as soon as possible). The OS will also have a bunch of other tasks that need to be accomplished but the can wait.

so for Q1 priority is correct, but why? Ask yourself why would a RTOS need to ensure that certain processes get executed first?

What is the difference between a microkernel and monolithic?
A monolithic kernel was the first model of an OS that was developed. Developer put everything that the kernel could ever possibly need into kernel space. This carries a bunch of extra overhead. Why would this be bad for a RTOS?
A micro kernel is one where just the bare minimum is included in the kernel, and any additional functionality that is needed needs to be built and run in user space.
Why might this be good for a RTOS?

Preemptive scheduling allows the OS to interrupt an executing process and allow another process to take over. Think about drivers pulling over to the side of the road to allow an emergency vehicle by.
Non preemptive is the opposite. Once an process is allocated some execution time that process is allowed to finish its time before being interrupted.
So which do you think would be better for a RTOS?

type of RTOS
Monolithic kernels
Micro kernel
preemptive kernel
non preemptive kernel

which one kernel support RTOS ?

I am asking preemptive kernel non preemptive kernel not for scheduling ?

 

[cpscdave]

type of RTOS
Monolithic kernels
Micro kernel
preemptive kernel
non preemptive kernel

which one kernel support RTOS ?

I am asking preemptive kernel non preemptive kernel not for scheduling ?

Well any of them you could use for a RTOS. But I think you would go for a preemptive microkernel

 

[rcgldr]

The term scheduling normally applies to a batch type situation where there are a list of jobs to be run on a multi-tasking (or single tasking) operating system. One goal could be to complete all jobs in the shortest time possible, but with constraints just as some jobs having higher priority than other jobs. This applies more to main frames than personal computers or embedded devices.

A true RTOS should be preemptive, switching to higher priority threads based on events. Threads pend on these events to allow lower priority threads to run. A non-preemptive operating system relies on the threads to make calls to operating system functions to allow context switches to take place, sometimes called round robin scheduling. A real time application can be implemented with a non-preemptive operating system, but I'm not sure if that should be called an RTOS since the critical timing requirements are handle in thread code instead of by the operating system. In some preemptive situations, every thread has a different priority, so no time slicing is needed to share time between threads of equal priority.

 

[vead]

Well any of them you could use for a RTOS. But I think you would go for a preemptive microkernel

there are two type of kernel

Monolithic kernels
Micro kernel

Monolithic kernels may be preemptive or non preemptive
preemptive Monolithic kernels
non preemptive Monolithic kernels

Micro kernel may be preemptive or non preemptive
preemptive Micro kernel
non preemptive Micro kernel

 

[FactChecker]

"Real-time" has a variety of meanings. "Hard real time" control systems often use frequency based scheduling. They have a set of programs that must run in a specified order at a strictly scheduled rate. These programs have top priority and do not get interrupted. Essential hardware interrupts are usually handled by other processors. Event-driven or background tasks are run in the remaining time and can be interrupted. Kernel operations are kept as small as possible and divided up so that uninterruptable parts are done in very short times.

 

[vead]

I have little bit doubt

does one RTOS support one or more then one kernel ?

and same does one RTOS support one or more then one scheduling process

 

[FactChecker]

There are no official rules or definitions. OS developers do whatever is needed for the type of use they are anticipating. But there are some general conventions.

The kernel is an abstract layer of software between the applications and the hardware. I think you would say there is only one. Some operating systems divide the computer resources and time so that different processes run as though they are running on different operating systems, but I think there is only one kernel, even in those systems.

There can be combinations of scheduling modes working simultaneously in the same OS. They would have to be coordinated into a single scheduling process or they would conflict with each other.

 

[vead]

There are no official rules or definitions. OS developers do whatever is needed for the type of use they are anticipating. But there are some general conventions.

The kernel is an abstract layer of software between the applications and the hardware. I think you would say there is only one. Some operating systems divide the computer resources and time so that different processes run as though they are running on different operating systems, but I think there is only one kernel, even in those systems.

There can be combinations of scheduling modes working simultaneously in the same OS. They would have to be coordinated into a single scheduling process or they would conflict with each other.

that means we can use one or more scheduling for one real time operating system

f

 

[FactChecker]

Yes. If you are designing the RTOS, you will include the combinations that will get the job done for the targeted user (maybe allow frequency based schedule for some tasks and FIFO queue schedule for other tasks). If you are a user, you will need to live with the scheduler options that the RTOS provides. RTOS designers try hard to give flexibility to the user so their RTOS has a large market. An advanced user programmer can often work within an RTOS to get whatever he needs. In an extreme case, a user might allocate a slice of processor time to his own task that schedules subtasks any way he wants.

 

[vead]

Interprocess communication for real time operating system

Interprocess communication is process of operating system that allow one process to communicate with another processes

for example - email , chatting

that means we can send message from one os to another

shared memory - it can be in the form of shared memory
queue - it can be in the form of queue
mail box - it can be in the form of message


can someone explain little bit what is interprocess communication for RTOS

 

[cpscdave]

Interprocess communication for real time operating system

Interprocess communication is process of operating system that allow one process to communicate with another processes

for example - email , chatting

that means we can send message from one os to another

shared memory - it can be in the form of shared memory
queue - it can be in the form of queue
mail box - it can be in the form of message


can someone explain little bit what is interprocess communication for RTOS

Similar as before there is no reason why you cannot use any of these methods for IPC in a RTOS. The questions you need to ask yourself is what properties of each will be of the best benefit for a RTOS.

Shared Memory is fast but as the memory is shared you will need to ensure that the processes lock the memory (eg via semaphores) to avoid race conditions

queue, the data needs to be copied to and from the queue, and then there is the overhead associated with managing the queue. How does the process know that there is something in the queue?? Generally a queue would only be 1 direction, so if 2 processes talked back and forth you would need multiple queues

Mail Box, some process (most likely the kernel) will have to manage the the mail boxes and again how does the process know that it has mail? and again the conents will have to be copied into the processes memory.

For a RTOS I would argue that the best method would be the shared memory approach. It seems to have the least overhead, and the processes can be "smart" and be built to give up control when they get blocked trying to access the shared memory, or set up so they can't be interupted when writing to the shared memory.

 

[rcgldr]

can someone explain little bit what is interprocess communication for RTOS

The term process is often used to refer to multiple processes, each with it's own memory space. Some startup mechanism or initial assumptions are needed for the processes to communicate (named shared memory, named handles, one process spawning the other processes and passing handle values on the command line used to invoke the other processes, ... ).

The alternative is a multi-threaded application, all of which share a common address space.

As for queues or mailboxes, the most common implementations I've seen internally use either a circular buffer or a linked list. In the case of a linked list, the calling code may have to deal with the nodes directly, or the calling code provides a buffer, and the operating system, copies data between the caller's buffer and internal linked list nodes. The nodes or the caller's buffer may include additional pointers to data.

 

[vead]

I am not really going to design I just want to learn something before design
I want to design my real time operating system , so I need features , requirement component and tool

I need to develop program For real time operating system
my effort
1)basic tool
compiler
linker
debugger

2)language
c language

3)requirement
requirement of real time os should be fast

features
kernel - micro kernel
scheduler - real time scheduler
multitasking - multitasking
scheduling - preemptive schedulingI think I have forgotten some features

 

[FactChecker]

I think I have forgotten some features

If you haven't already, look into the Board Support Package (BSP) (see http://en.wikipedia.org/wiki/Board_support_package ). I think that the board manufacturers usually write the BSP. Even if you don't program it you will want to define an interface that works with it. And it may give you some clues about what the OS needs to do.

 

[vead]

I am having problem to understand some statement

kernel is not modular,
kernel is not fault tolerant ,
kernel is not configurable
kernel is not power optimized

can anyone explain little bit ?

 

[rcgldr]

I am having problem to understand some statement
kernel is not modular,
kernel is not fault tolerant ,
kernel is not configurable
kernel is not power optimized
can anyone explain little bit ?

Where did you get these statements from?

modular - the code is separated into reasonably small functions and reasonably small source files.

fault tolerant - being able to handle faults, usually a reference to a fault in the hardware (not a fault in the software). Mostly an issue when health (like xray / electron beam machine) or a lot of money is at risk.

configurable - This probably means run time configurable, as the source or make files can be modified to make the kernel source time or compile time configurable.

power optimized - some processors have a low power state which can be used in a kernal when no tasks are runnable (all of them in some sort of wait state). The low power state for some processors is invoked by a halt instruction.

 

[vead]

Where did you get these statements from?

.

I looked pdf in which I seen statement why os is not suitable in real time os

kernel is not modular, fault tolerant , configurable
take too much space , not design for critical application

kernel is not modular- code is separated

kernel is not fault tolerant - kernel can not tolerate fault

kernel is not configurable- code and source can not modify

 

[nsaspook]

Whether or not a OS kernel is modular in design is not a RTOS requirement but it can speed up OS development and/or OS design greatly. The standard Linux kernel can be generated in many different configurations. Most non-RTOS Linux distributions only include the critical components in the kernel needed to boot the OS from bare hardware and BIOS file blocks before external user file system modules are loaded to provide the needed files that contain the modules for the rest of the system to load. Once the OS is running it's much easier to develop code, compile a module, load and unload modules with different loading options to test hardware/software drivers instead of creating a new kernel and rebooting each time during testing.

 

[vead]

Whether or not a OS kernel is modular in design is not a RTOS requirement but it can speed up OS development and/or OS design greatly. The standard Linux kernel can be generated in many different configurations. Most non-RTOS Linux distributions only include the critical components in the kernel needed to boot the OS from bare hardware and BIOS file blocks before external user file system modules are loaded to provide the needed files that contain the modules for the rest of the system to load. Once the OS is running it's much easier to develop code, compile a module, load and unload modules with different loading options to test hardware/software drivers instead of creating a new kernel and rebooting each time during testing.

can you tell me some reason why os is not suitable in real time os

 

[nsaspook]

can you tell me some reason why os is not suitable in real time os

http://forum.allaboutcircuits.com/attachment.php?attachmentid=69951&d=1403281255

 

[rcgldr]

can you tell me some reason why os is not suitable in real time os

Which OS is considered not suitable? Maybe I missed a link to the pdf file you mentioned?