Commit a239d2f8 authored by Jonas Künzli's avatar Jonas Künzli Committed by overleaf
Browse files

Update on Overleaf.

parent 610eff4a
% kuenzlij
% !TeX root = ../main.tex
\ownsection{Real-Time OS}
Why is a desktop OS not suited?
\begin{compactitem}
\item Monolithic kernel is too feature rich.
\item Monolithic kernel is not modular, fault tolerant, configurable, modifiable
\item Is too resource hungry (memory, computation time)
\item Not designed for mission-critical applications
\item Timing uncertainty too large
\end{compactitem}
Advantages and properties of embedded OS
\begin{compactitem}
\item OS can be fitted to individual need: Remove unused functions, conditional compilation depending on hardware, replace dynamic data by static data
\item Improved predictability because of scheduler
\item Interrupts can be employed by any process
\item Device drivers handled by tasks instead of hidden drivers $\implies$ everything goes through scheduler\\
\includegraphics[width=1\linewidth]{RTOS_drivers}
\item Protection mechanisms not always necessary (Processes tested and considered reliable). $\implies$ Tasks can do their own I/O, including interrupts
\end{compactitem} ~\newline
\ownsubsection{Requirements for RTOS (6-10)} \oldline
\begin{compactitem}
\item The timing behaviour of the OS must be predictable
\subitem For all services upper bound on execution time
\subitem Must be deterministic (upper bounds on blocking times)
\item OS must manage the timing and scheduling
\subitem OS may have to be aware of deadlines unless scheduling is done offline
\subitem OS must provide precise time services
\item OS must be fast
\end{compactitem} ~\newline
\ownsubsection{Main Functionality of RTOS Kernel (6-13)} \oldline
\begin{compactitem}
\item \textbf{Task management:} Execution of quasi-parallel tasks on a processor using processes or threads
\item \textbf{CPU scheduling:} guaranteeing deadlines, minimizing waiting times, fairness in granting resources
\item \textbf{Process synchronization:} critical sections, semaphores, monitors, mutual exclusion
\item \textbf{Inter-process communication:} buffering
\item \textbf{Real-time clock:} as an internal time reference
\end{compactitem} ~\newline
\ownsubsection{Task states (6-15)} \oldline
\begin{center}
\includegraphics[width=0.9\columnwidth]{OS1}
\end{center}
\begin{compactitem}
\item \textbf{Run:} A task enters this state when it starts executing on the processor
\item \textbf{Ready:} State of tasks that are ready to execute but cannot be executed because processor is assigned to another task
\item \textbf{Wait:} A task enters this state when it executes a synchronization primitive to wait for an event, e.g. a wait primite or a semaphore.
\item \textbf{Idle:} A periodic job enters this state when it completes its execution and has to wait for the beginning of the next period.
\end{compactitem}
~
\begin{definition}{Threads}
A thread is the smallest sequence of programmed instructions that can be managed independently by a scheduler. Multiple threads can exist within the same process and share resources such as memory. The \textcolor{red}{Thread Control Block (TCB)} stores information needed to manage and schedule a thread.
\end{definition} ~\newline
\ownsubsection{Communication Mechanisms (6-20)}
\textbf{Problem:} The use of shared resources for implementing message passing schemes may cause priority inversion and blocking.
\newline
\textbf{Synchronous communication:}
\begin{compactitem}
\item Synchronization for a message transfer (\textcolor{red}{rendez-vous}) $\implies$ They have to wait for each other
\item When off-line scheduling: Transformation into precedence constraints.
\end{compactitem}
\textbf{Asynchronous communication:}
\begin{compactitem}
\item Usage of \textbf{Mailbox} (shared memory buffer, FIFO-queue with fixed cap.) $\implies$ Tasks do not have to wait for each other
\item Better suited for real-time systems than synchronous communication
\item Problem: Blocking behaviour if channel is full or empty
\end{compactitem} ~\newline
\ownsubsection{Classes of embedded OS (6-23)}
\textbf{Class 1: Fast Proprietary Kernels}: For hard real-time systems, these kernels are questionable, because they are designed to be fast, rather than to be predictable in every respect. ~\newline
\textbf{Class 2: Extensions to Standard OS}: Real-time extensions to standard OS. Attempt to exploit comfortable main stream OS. RT-kernel running all RT-tasks, \textbf{standard-OS executed as one task.} \newline
Pro: Crash of standard-OS does not effect RT-tasks\newline
Con: RT-tasks cannot use standard-OS services
\begin{center}
\includegraphics[width=0.9\columnwidth]{OS2}
\end{center}
......@@ -39,8 +39,9 @@
\input{chapters/Chapter7.tex}
%\input{chapters/resourceSharing.tex}
\newpage
\input{chapters/realtimeOS.tex}
\newpage
%% ghoert
%\input{chapters/realtimeOS.tex}
%\newpage
\input{chapters/systemComponents.tex}
\newpage
% \input{chapters/communication.tex}
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment