Merge branch 'master' of ssh://vo20.nl/home/git/repos/uva

os/ass4/report/report.tex

@@ -147,16 +147,52 @@ 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
+De implementatie van locks is moeilijk, doordat een enkele keer dat een lock
+niet (goed) 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
+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.
 
+Naast de bovenstaande deadlocksituatie, kan het ook voorkomen dat een thread
+nooit de mogelijkheid krijgt om de tweede lock te krijgen. Als een thread
+oneindig lang op zijn tweede lock moet wachten, spreekt men van
+\emph{starvation}. Dit is anders dan een deadlocksituatie omdat bij starvation
+maar een deel van de processen nooit zijn werk kan doen (bij deadlock kan geen
+enkel proces zijn werk doen).
+
 \subsection{Events versus threads}
 
+Een van de alternatieven voor threads is het gebruik van \emph{events}. Veel
+applicaties plaatsen de graphical user interface in een aparte thread om het
+programma optimaal zijn werk te kunnen laten doen, terwijl de gebruiker
+bijvoorbeeld met zijn muis over het venster beweegt. Events zouden hier een
+goede oplossing zijn omdat events veel minder tijd kost om te ontwikkelen voor
+een ontwikkelaar:
+
+\begin{enumerate}
+\item \emph{Timing dependencies} treden alleen op n\'a het plaatsvinden van een
+      event en zijn dus niet afhankelijk van proces scheduling. Een logbestand
+      is hierdoor veel gemakkelijker bij te houden.
+\item Geen synchronisatieprobleem doordat de events sequenceel worden
+      afgehandeld in plaats van parallel.
+\item Er vinden geen deadlock- en/of starvationsituaties meer plaats, doordat
+      er geen locks worden gebruikt die de threads in goede banen leidt.
+\item De ontwikkelaar kan gemakkelijker met een debugger werken, want
+      synchronisatie en parallelisme vormen geen problemen meer.
+\end{enumerate}
+
+\noindent
+Daarnaast werkt een \emph{event-based} applicatie veel effici\"enter dan een
+multithreaded applicatie als alleen een enkele CPU in het systeem aanwezig is.
+Dit komt doordat er geen \emph{locking overhead} en \emph{context switches}
+(tussen de threads) meer nodig zijn. In veel applicaties is het dan ook niet
+noodzakelijk om alles parallel te laten lopen. Daar moet wel een kanttekening
+bij worden geplaatst: als er meerdere CPU's aanwezig zijn en de taak in
+onafhankelijke subtaken is op te delen, dan geeft een multithreaded applicatie
+wel degelijk een voordeel. Dit gaat echt wel te kostte van veel ontwikkeltijd.
+
 % Events avoid concurrency as much as possible, threads embrace:
 % - Easy to get started with events: no concurrency, no preemption, no
 %   synchronization, no deadlock.