\documentclass[12pt]{article}

\usepackage[utf8]{inputenc}
%\usepackage[margin=2cm]{geometry}

\title{Howework 1 -- Programming Fundamentals 3}
\author{Claudio Maggioni}

\begin{document}
\maketitle
\section{Exercise 1}
\subsection{Question 1}
\texttt{MultipleUpdatesPerThread} is neither correct nor efficient. The reason for its uncorrectness is the unsynchronized access
of \emph{result}, which assigns unconsistent values to it: non-atomic evaluation of the statement \texttt{result += partialSum;}
can make one thread evaluate the new value for \emph{result} before another has finished writing to it, thus producing incorrect
results.

By synchronising the access to \emph{result}, we effectively make the application sequential, since only one thread at a time can
change result. Therefore, \texttt{MultipleUpdatesPerThread} runs even worse than \texttt{SequentialSum} since it has to cope with
all the synchronization overhead.
\subsection{Question 2}
While more efficient, \texttt{SingleUpdatePerThread} is still wrong because the access to  \emph{result} is still not synchronized.
Again, non-atomic evaluation of the statement \texttt{result += partialSum;} can make one thread evaluate the new value for \emph{result} before another has finished writing to it, thus producing incorrect
results.
\subsection{Question 6}
\texttt{CollectingResults} is the only Thread-safe implementation because it is the only one not to use a static field to compute
the final result. If multiple threads use anyone of the other classes concurrently, \emph{result} will be shared between the 
threads and all the results will be inconsistent. In order to solve this problem, either the entire \texttt{sum(...)} method must
be considered a critical section (defeating the point of concurrent access to the summing class) or the scope of result must be
bound to the thread (e.g. by making \emph{result} either a private field and making the inner classes non-static, or by making it
a local variable, as \texttt{CollectingResults} does).
\end{document}