Verified Commit 7eca1144 authored by Theo von Arx's avatar Theo von Arx
Browse files

Improve Resource sharing

parent 6a53f29b
% !TeX root = ../main.tex
\ownsection{Resource Sharing (7)}
Common resources are e.g. data structures, variables, main memory area, file, set of registers, I/O unit, ...\\
Many shared resource require \textcolor{red}{mutual exclusion} (\textcolor{red}{exclusive resources}) meaning only one thread can operate on the resource at same time.\\
% Common resources are e.g. data structures, variables, main memory area, file, set of registers, I/O unit, ...\\
% Many shared resource require \textcolor{red}{mutual exclusion} (\textcolor{red}{exclusive resources}) meaning only one thread can operate on the resource at same time.\\
\textbf{3 different types:}
\begin{description}
\item[Private Ressourcen] werden ausschliesslich von einem
Prozess/Thread benutzt.
\item[Geteilte Ressourcen] können von mindestens zwei u. U.
konkurrierenden Prozessen/Threads benutzt werden. Bei
gleichzeitiger Nutzung einer Ressource durch mehrere
Prozesse/Threads ohne weitere Gegenmassnahmen können z. B.
Dateninkonsistenzen auftreten, oder unleserliche Ausgaben auf
Drucker oder Monitor entstehen.
\item[Exclusive Resourcen] sind geteilte Resourcen, auf die jeweils nur ein
Thread zugreifen darf.
\end{description}
To protect exclusive resources:
\begin{itemize}
\item disable interrupts and preemption
\item use semaphores, mutex...
\item disable interrupts and preemption
\item use semaphores, mutex...
\end{itemize}
\textbf{Critical Section}\\
A piece of code executed under mutual exclusion constraints.
A piece of code executed under mutual exclusion constraints.
\begin{compactitem}
\item A task waiting for an exclusive resource is said to be \textcolor{red}{blocked}
......@@ -29,96 +43,96 @@ A low priority task holds a Semaphore and prevents a high priority task from run
\includegraphics[width=0.8\linewidth]{priority_inversion}
\textbf{Solutions:}
\textbf{Solutions:}
\begin{itemize}
\item \textbf{Disallow preemption} during the execution of critical sections. This may block unrelated tasks with higher priority unnecessarily :(.
\item
\textbf{Priority Inheritance Protocol (PIP)}: When a task $J_i$ blocks one or more higher priority tasks, it temporarily inherits the highest priority of the blocked tasks. Among equal priorities, it is \textbf{first come, first served}\newline
\textbf{Terms:}
\begin{itemize}
\item fixed \textcolor{red}{Nominal priority} $P_i$
\item \textcolor{red}{active priority} $p_i\geq P_i$.
\end{itemize}
Jobs $J_1,...,J_n$ are ordered with respect to nominal priority where $J_1$ has highest priority. Jobs do not suspend themselves. \newline
\textbf{Algorithm:}
\begin{compactitem}
\item Jobs are scheduled according to $p_i$
\item Jobs with same priority $\rightarrow$ First come first serve
\item When a job $J_i$ enters a critical section and it is blocked by a job with lower priority, $J_i$ gets blocked.
\item When job $J_i$ is blocked, it transmits its \underline{active} priority to the job $J_k$ that holds the semaphore. Job $J_k$ takes the priority $p_k = p_i$.
\item When $J_k$ finished the crit. sec., it unlocks the semaphore and the blocked job with the highest priority gets awakened.
\item If no other jobs are blocked by $J_k$, then $p_k$ is set to $P_k$, otherwise it is set to the highest priority of the jobs blocked by $J_k$ (In the case of nested semaphores)
\end{compactitem}
Example with nested critical sections: We can see how the active priority of Job 3 changes with time\\
\includegraphics[width=0.9\linewidth]{PIP_nested_priorities}
When $J_2 $/$J_3$ wants to enter critical section $p_3$ becomes higher.
\begin{compactitem}
\item \textcolor{red}{Direct Blocking}: Higher-priority job tries to acquire a resource held by a lower-priority job and is blocked by it.
\item \textcolor{red}{Push-through Blocking}: medium-priority job is blocked by a lower-priority job that has inherited a higher priority from a job it directly blocks.
\end{compactitem}
~
\includegraphics[width=\linewidth]{images/blocking.JPG}
\textbf{Problems:}
\begin{itemize}
\item Deadlocks: can be solved with Watchdog timers
\end{itemize}
\item and other methods based on \textcolor{red}{resource access protocols} (PCP,SRP, see 7-13)
\item \textbf{Disallow preemption} during the execution of critical sections. This may block unrelated tasks with higher priority unnecessarily :(.
\item
\textbf{Priority Inheritance Protocol (PIP)}: When a task $J_i$ blocks one or more higher priority tasks, it temporarily inherits the highest priority of the blocked tasks. Among equal priorities, it is \textbf{first come, first served}\newline
\textbf{Terms:}
\begin{itemize}
\item fixed \textcolor{red}{Nominal priority} $P_i$
\item \textcolor{red}{active priority} $p_i\geq P_i$.
\end{itemize}
Jobs $J_1,...,J_n$ are ordered with respect to nominal priority where $J_1$ has highest priority. Jobs do not suspend themselves. \newline
\textbf{Algorithm:}
\begin{compactitem}
\item Jobs are scheduled according to $p_i$
\item Jobs with same priority $\rightarrow$ First come first serve
\item When a job $J_i$ enters a critical section and it is blocked by a job with lower priority, $J_i$ gets blocked.
\item When job $J_i$ is blocked, it transmits its \underline{active} priority to the job $J_k$ that holds the semaphore. Job $J_k$ takes the priority $p_k = p_i$.
\item When $J_k$ finished the crit. sec., it unlocks the semaphore and the blocked job with the highest priority gets awakened.
\item If no other jobs are blocked by $J_k$, then $p_k$ is set to $P_k$, otherwise it is set to the highest priority of the jobs blocked by $J_k$ (In the case of nested semaphores)
\end{compactitem}
Example with nested critical sections: We can see how the active priority of Job 3 changes with time\\
\includegraphics[width=0.9\linewidth]{PIP_nested_priorities}
When $J_2 $/$J_3$ wants to enter critical section $p_3$ becomes higher.
\begin{compactitem}
\item \textcolor{red}{Direct Blocking}: Higher-priority job tries to acquire a resource held by a lower-priority job and is blocked by it.
\item \textcolor{red}{Push-through Blocking}: medium-priority job is blocked by a lower-priority job that has inherited a higher priority from a job it directly blocks.
\end{compactitem}
~
\includegraphics[width=\linewidth]{images/blocking.JPG}
\textbf{Problems:}
\begin{itemize}
\item Deadlocks: can be solved with Watchdog timers
\end{itemize}
\item and other methods based on \textcolor{red}{resource access protocols} (PCP,SRP, see 7-13)
\end{itemize}
\ownsection{Timing Anomaly (7-26)}
Many software and system architectures are fragile since \textcolor{red}{monotonicity} does not hold in general (= making a part of the system operate faster does not necessarily lead to a faster system execution).\newline
\textbf{Examples:}
\begin{itemize}
\item single processor with critical section (7-27):\\ processor that is 2x as fast can lead to deadline miss.
\item Richards Anomalies (multiprocessor) (7-28):\\
\begin{itemize}
\item slower due to more processor cores
\item slower due to faster computation
\item slower due to removing precedence constraint (fixe Reihenfolge)
\end{itemize}
\item single processor with critical section (7-27):\\ processor that is 2x as fast can lead to deadline miss.
\item Richards Anomalies (multiprocessor) (7-28):\\
\begin{itemize}
\item slower due to more processor cores
\item slower due to faster computation
\item slower due to removing precedence constraint (fixe Reihenfolge)
\end{itemize}
\end{itemize}
\ownsection{Communication and Synchronization (7-32)}
The use of shared memory for communication between tasks may cause:
\begin{itemize}
\item priority inversion
\item blocking
\item priority inversion
\item blocking
\end{itemize}
Solutions:
\begin{itemize}
\item shared medium must be “thread safe”
\item data exchange must be protected by critical sections
\item shared medium must be “thread safe”
\item data exchange must be protected by critical sections
\end{itemize}
\ownsubsection{Synchronous Communication (7-34)}
\begin{itemize}
\item Tasks must be synchronized (rendez-vous) to exchange data
\item both must be ready at the same time $\rightarrow$ waiting time
\item Communication needs synchronization, therefore the timing of the communication partners is linked
\item Tasks must be synchronized (rendez-vous) to exchange data
\item both must be ready at the same time $\rightarrow$ waiting time
\item Communication needs synchronization, therefore the timing of the communication partners is linked
\end{itemize}
\ownsubsection{Asynchronous Communication (7-35)}
\begin{itemize}
\item The sender deposits a message into a channel from where the receiver retrieves the message.
\item Tasks don't have to wait for each other
\item more suited for real-time systems
\item \textbf{Mailbox:} shared memory buffer with send and retrieve functions and a fixed capacity (FIFO)
\item \textbf{Problem:} Blocking behavior if the channel is full or empty. alternative approach provided by cyclical asynchronous buffers (see next section) or double buffering.
\item The sender deposits a message into a channel from where the receiver retrieves the message.
\item Tasks don't have to wait for each other
\item more suited for real-time systems
\item \textbf{Mailbox:} shared memory buffer with send and retrieve functions and a fixed capacity (FIFO)
\item \textbf{Problem:} Blocking behavior if the channel is full or empty. alternative approach provided by cyclical asynchronous buffers (see next section) or double buffering.
\end{itemize}
Beispiel auf Folie (7-36)\\
\includegraphics[width=0.9\columnwidth]{images/mailbox.JPG}
\ownsubsection{Cyclical Asynchronous Buffers (CAB)(7-40)}
\begin{itemize}
\item non-blocking communication between tasks (the sender and receiver are never blocked)
\item a message is not consumed (extracted) by a receiver but maintained until overwritten by a new message.
\item several readers can read at the same time
\item max. number of internal buffers must be equal to the number of tasks +1 that uses the data structure.
\end{itemize}
\ No newline at end of file
\item non-blocking communication between tasks (the sender and receiver are never blocked)
\item a message is not consumed (extracted) by a receiver but maintained until overwritten by a new message.
\item several readers can read at the same time
\item max. number of internal buffers must be equal to the number of tasks +1 that uses the data structure.
\end{itemize}
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