\begin{slide}{Einleitung, Definitionen}


Eine Klasse heißt \emph{thread-sicher},
\begin{itemize}\itemsep 0pt \parskip 1pt
\item 
  wenn sie korrekt ist ($=$ ihre Spezifikation erfüllt)
\item
  auch bei Benutzung (Methodenaufruf) durch mehrere Threads
  mit beliebiger (durch das Laufzeitsystem ermöglichter) Ausführungsreihenfolge
\item
  und ohne zusätzliche Synchronisation der Aufrufer.
\end{itemize}

thread-sichere Klassen synchronisieren selbst 
(Clients synchronisieren gar nicht)

zustandslose Klassen (Objekte) sind thread-sicher

\begin{small}
(Brian Goetz et al.: \emph{Java Concurrency in Practice},
A-W, 2006; Kap. 2/3)
\end{small}

\end{slide}


\begin{slide}{Zustandsänderungen}

wenn mehrere Threads eine gemeinsame Variable
ohne Synchronisation benutzen, ist das Programm nicht thread-sicher.

Auswege:
\begin{itemize}
\item 
  die Variable nicht an verschiedene Threads exportieren
\item
  die Variable als unveränderlich (final) deklarieren
\item 
  Zugriffe synchronisieren
\end{itemize}

\end{slide}

\begin{slide}{Object Confinement}

Sichtbarkeit von Objekten (Objektverweisen) einschränken:

\begin{itemize}
\item Thread confinement: nur in einem Thread sichtbar,

  Beispiel: GUI-Frameworks (mit einem GUI-Thread, den der
  Programmierer der Applikation nie sieht)
\item Stack confinement: Variable lebt nur während
  eines Methodenaufrufs 

  (im Laufzeitkeller im Frame dieses Aufrufs)
\end{itemize}
gefährlich sind immer ungewollt exportierte Verweise,
z. B. auf \verb|this| im Konstuktor.
\end{slide}

\begin{slide}{Übung: \emph{this} escapes during construction}

  \begin{itemize}
  \item \verb|class C { final int foo; ...}|

    Attribut \verb|foo| wird erst im Konstruktor initialisiert
  \item der Konstruktor exportiert aber vorher \verb|this|,
    dann kann das nicht initialisierte \verb|foo| 
    in einem anderen Thread beobachtet werden
  \item benutze \verb|class Receiver { void receive (C x) { ... } }|
  \item versteckter Export von \verb|this|: als statischer
    Vorgänger einer lokalen Klasse (z. B. ActionListener)
  \end{itemize}
  

\end{slide}

\begin{slide}{Atomare Aktionen}

  \begin{itemize}
  \item 
Operationen $A_1$ und $A_2$ sind \emph{atomar zueinander},

wenn zu keinem Zeitpunkt ein Thread $T_1$ die Operation $A_1$ ausführt
und gleichzeitig ein Thread $T_2$ die Operation $A_2$ ausführt.
\item
Operation $A$ ist \emph{atomar},

wenn sie atomar zu jeder anderen Operation ist
(einschließlich sich selbst).
  \end{itemize}

\end{slide}

\begin{slide}{Zusammengesetzte Aktionen}

check-then-act
\begin{verbatim}
Stack<Foo> l = ... ;
if (! l.empty()) { Foo x = l.pop (); ... }
\end{verbatim}

read-modify-write
\begin{verbatim}
int x = ... ;   x = x + 1 ;
\end{verbatim}

sind nicht atomar und damit nicht thread-sicher

Auswege:
\begin{itemize}
\item Datentypen mit atomaren Operationen (AtomicLong) (später)
\item Locking (jetzt)
\end{itemize}

\end{slide}



