Added report of Operating System's assignment 4.

os/ass4/report/.gitignore

+*.log
+*.toc
+*.aux
+report.pdf
+report-dot2tex*
+dot2tex.cache

os/ass4/report/report.tex

+\documentclass[10pt,a4paper]{article}
+\usepackage[utf8]{inputenc}
+\usepackage{amsmath}
+\usepackage{amsfonts}
+\usepackage{amssymb}
+
+\usepackage{enumerate}
+\usepackage{listings}
+\usepackage{url}
+\usepackage{float}
+\usepackage[toc,page]{appendix}
+
+\usepackage[dutch]{babel}
+\usepackage{listings}
+
+\lstset{
+language=C,
+numbers=left,
+numberstyle=\footnotesize,
+stepnumber=1,
+numbersep=5pt,
+showspaces=false,
+showstringspaces=false,
+showtabs=false,
+tabsize=4,
+captionpos=t,
+breaklines=false
+}
+
+% dot graphs
+\usepackage{dot2texi}
+\usepackage{tikz}
+\usetikzlibrary{shapes,arrows}
+
+\title{Operating systems opdracht 4: POSIX threads}
+\author{Sander van Veen \& Tadde\"us Kroes \\
+        6167969 \& 6054129 \\
+		\url{sandervv@gmail.com} \& \url{taddeuskroes@hotmail.com} }
+
+\begin{document}
+
+\definecolor{darkgray}{rgb}{0.95,0.95,0.95}
+
+\maketitle
+
+\tableofcontents
+
+\pagebreak
+
+\section{Inleiding tot threads}
+
+Steeds meer computers (en servers al helemaal) hebben meer dan \'e\'en processor
+aan boord. Meerdere processoren maken het mogelijk om taken parallel uit te
+voeren, maar hiervoor dient men wel meerdere taken te hebben (anders valt er
+weinig parallel uit te voeren). Het gebruik van threads maakt het mogelijk om
+bijvoorbeeld:
+
+\begin{enumerate}
+\item bepaalde problemen helderder te programmeren, doordat diverse onderdelen
+      van een programma die afwisselend moeten worden uitgevoerd, in hoge mate
+      onafhankelijk van elkaar kunnen worden beschreven.
+\item deeltaken, zoals het afhandelen van service-aanvragen in een server
+      programma, eenvoudig af te splitsen.
+\item multi-processorsystemen beter te benutten door I/O operaties in een
+      gescheide thread te laten draaien en meerdere taken tegelijkertijd te
+      laten draaien.
+\end{enumerate}
+
+% What Are Threads Used For?
+% 
+% Operating systems: one kernel thread for each user process.
+% 
+% Scientific applications: one thread per CPU (solve problems more quickly).
+% 
+% Distributed systems: process requests concurrently (overlap I/Os).
+% 
+% GUIs:
+% - Threads correspond to user actions; can service display during long-running
+%   computations.
+% - Multimedia, animations.
+
+\subsection{Threads en performance}
+Threads hebben een shared state (zoals een fork van een process) en shared
+memory en zijn daarom de meest voor de hand liggende oplossing om een hoge
+\emph{concurrency}\footnote{Programma's die in staat zijn om een hoge
+concurrency af te handelen, kunnen snel/goed een groot aantal gelijktijdige
+requests/users aan. Concurrency is belangrijk voor servers.} aan te kunnen.
+
+Threads zijn in feite subprogramma's die voor een groot deel onafhankelijk van
+elkaar functioneren. Merk op dat het mogelijk is om threads niet meer
+onafhankelijk van elkaar te maken door \texttt{join()} als host\footnote{In dit
+geval is een \emph{host} de thread die andere threads aanmaakt.} op een of meer
+threads uit te voeren. Dan voegen de threads samen en wordt de code na de
+\texttt{join()} weer sequenceel uitgevoerd. Soms kan geen \texttt{join()} worden
+uitgevoerd op een thread, want een thread kan als \texttt{detached} worden
+ingesteld.
+
+Niet in alle gevallen zijn taken in threads op te delen. Als de taak niet op te
+delen is in stukken die onafhankelijk van elkaar kunnen worden uitgevoerd,
+levert een multi-processor systeem geen performance winst op. Het kan ook zijn
+dat het opdelen van een process in meerdere onafhankelijke stukken geen winst
+oplevert voor de throughput op netwerk niveau:
+
+\begin{quote}First, the more threads handling a parallelized request, the larger
+the overall response time. Often all parallel tasks must finish before a request
+is completed, and thus the overall response time becomes the maximum response
+time of any subtask, and more subtasks will push further into the long tail of
+subtask response times. With 10 subtasks, a one-in-a-thousand chance of
+suboptimal process scheduling will affect 1 percent of requests (recall that the
+request time is the maximum of all subrequests), but with 1,000 subtasks it will
+affect virtually all requests.\footnote{Tekst afkomstig uit
+\url{http://research.google.com/pubs/archive/36448.pdf}, geschreven door Urs
+Hölzle (senior vice president of operations van Google).}\end{quote}
+
+Het kan dus zijn dat het opdelen van processen in deeltaken een negatieve impact
+heeft op de totale throughput. Het opdelen van een aantal onafhankelijke
+requests over meerdere servers zorgt voor lagere gemiddelde response time. Maar
+het opdelen van een individuele request over meerdere servers kan gemiddeld
+langer duren. Dus het niveau waarop taken worden verdeeld is belangrijk.
+
+\subsection{Waarom zijn threads zo moeilijk?}
+
+De implementatie van een goed werkende multithreaded applicatie is moeilijk. Dit
+komt doordat threads te maken hebben met \emph{pre-emptive scheduling}, meerdere
+\emph{independent execution streams} en synchronisatieproblemen.
+
+Debuggers zijn in veel gevallen een stuk minder geschikt om te gebruiken bij een
+multithreaded applicatie. Doordat code tegelijkertijd kan worden uitgevoerd in
+plaats van sequenceel, is het debuggen van een stuk code lastiger. Het geheugen
+kan namelijk in de tussentijd zijn aangepast door een andere thread, terwijl dat
+bij een sequenceel programma niet kan.
+
+Omdat threads door middel van \emph{pre-emptive scheduling} parallel worden
+uitgevoerd, is het aanmaken van een logbestand met alle acties die de threads
+uitvoeren lastig. De uitvoer van het logbestand zal afhankelijk zijn van de
+manier waarop de \emph{process scheduler} de threads heeft ingedeeld.
+
+Tot slot is er ook nog een probleem met het gebruik van shared memory tussen de
+threads: synchronisatie. Als twee threads met hetzelfde stukje geheugen werken,
+dan kan het probleem optreden dat een van de twee threads de waarde van de
+andere thread overschrijft, zonder dat de threads dit van elkaar weten.
+
+Een van de oplossingen voor het synchronisatieprobleem is het gebruik van
+\emph{locks} en/of \emph{conditions}. Door middel van locks is het mogelijk om
+een stuk geheugen tijdelijk af te schermen voor een van de threads en weer
+beschikbaar te stellen als de thread de waarde heeft kunnen bijwerken. Als de
+lock wordt opgeheven (waarde is bijgewerkt), dan kunnen de andere threads pas
+dat stuk geheugen veranderen.
+
+De implementatie van locks is moeilijk, doordat een enkele keer dat een lock niet
+wordt gebruikt de data corrupt is. Alle threads moeten dus hetzelfde lock
+mechanisme hanteren, anders is er geen zekerheid dat de data niet in de
+tussentijd door een andere thread is overschreven. Het tweede probleem met locks
+is dat er een \emph{deadlock} situatie kan optreden. Dit houdt in dat twee
+threads eindeloos op elkaar wachten: thread 1 beschikt over lock 1 en heeft lock
+2 nodig, en thread 2 verkeert in de omgekeerde situatie.
+
+\subsection{Events versus threads}
+
+% Events avoid concurrency as much as possible, threads embrace:
+% - Easy to get started with events: no concurrency, no preemption, no
+%   synchronization, no deadlock.
+% - Use complicated techniques only for unusual cases.
+% - With threads, even the simplest application faces the full complexity.
+% 
+% Debugging easier with events:
+% - Timing dependencies only related to events, not to internal scheduling.
+% - Problems easier to track down: slow response to button vs. corrupted memory.
+% 
+% Events faster than threads on single CPU:
+% - No locking overheads.
+% - No context switching.
+% 
+% Events more portable than threads.
+% 
+% Threads provide true concurrency:
+% - Can have long-running stateful handlers without freezes.
+% - Scalable performance on multiple CPUs.
+% 
+% Should You Abandon Threads?
+% 
+% No: important for high-end servers (e.g. databases).
+% 
+% But, avoid threads wherever possible:
+% - Use events, not threads, for GUIs, distributed systems, low-end servers.
+% - Only use threads where true CPU concurrency is needed.
+% - Where threads needed, isolate usage in threaded application kernel: keep
+%   most of code single-threaded.
+
+\pagebreak
+
+\section{De opgave}
+
+Deze opgave gaat over het ``Dinerende Filosofen Probleem''\footnote{
+\url{http://en.wikipedia.org/wiki/Dining\_philosophers\_problem}}. De
+probleemstelling is simpel: Er is een tafel, met een $n$ filosofen, en $n$
+aantal eetstokjes. De filosofen willen afwisselend eten en nadenken. Elke
+filosoof heeft twee eetstokjes nodig om te eten. Voor deze opgave dient men een
+simulator te maken die dit probleem nabootst.
+
+\subsection{Code example}
+
+\begin{lstlisting}[numbers=none,backgroundcolor=\color{darkgray}]
+code example
+\end{lstlisting}
+
+\pagebreak
+
+\begin{appendices}
+
+\section{main.h}
+
+\lstinputlisting[xleftmargin=-0.5in,language=c]{../main.h}
+
+\section{main.c}
+
+\lstinputlisting[xleftmargin=-0.5in,language=c]{../main.c}
+
+\end{appendices}
+
+\end{document}