diff --git a/Bilder/CPU_Mehrprozessor.png b/Bilder/CPU_Mehrprozessor.png
new file mode 100644
index 0000000..87bdd91
Binary files /dev/null and b/Bilder/CPU_Mehrprozessor.png differ
diff --git a/Kapitel/03_Speicher.tex b/Kapitel/03_Speicher.tex
index d0a86cb..4a668f1 100644
--- a/Kapitel/03_Speicher.tex
+++ b/Kapitel/03_Speicher.tex
@@ -195,10 +195,11 @@ $\Rightarrow$ sobald das Zugriffsmuster Lokalität aufweist, ergibt sich eine be
 	Schreibzugriff durch die \acs{CPU} findet im \acl{HS} statt. Parallel dazu müssen die Daten im Cache invalidiert (schlecht) oder ebenfalls geschrieben werden (gut).
 	\begin{itemize}[leftmargin=5mm]
 		\item[$\oplus$] optimale Konsistenz der Daten
-		\item[$\ominus$] Schreiben nur in  \acl{HS}-Geschwindigkeit möglich
+		\item[$\ominus$] Schreiben nur in  \acs{HS}-Geschwindigkeit möglich
 	\end{itemize}
 \end{paracol}
 
+\hspace*{-5mm}
 \begin{tabular}{p{32mm}|p{62mm}|p{62mm}}
 	\textbf{Cachearchitektur} \newline \newline \textbf{Schreibstrategie}
 	& \textbf{Write-Bac}k
@@ -603,3 +604,41 @@ Dividieren ist damit überflüssig (alle Zeitscheiben sind gleich lang): Additio
 Bei der Verdrängung gibt ein Problem bei der Suche nach der niedrigsten \enquote{Häufigkeit}. \newline
 $\Rightarrow$ evtl. Lösung über eine bei Beginn jedes Zeitslots neu aufzubauende verkettete Liste. \newline
 \phantom{$\Rightarrow$ }Hier gibt es viel Platz für Optimierungen der \acs{CPU}-Hersteller.
+
+\subsection{Cache bei Mehrprozessor-/Mehrkernsystemen} \index{Mehrkernprozessor}
+In \autoref{fig:cpu_mehrprozessor} besitzt jeder Kern einen eigenen Cache. Möglich wäre auch ein gemeinsamer Cache. Verglichen werden diese beiden Möglichkeiten in \autoref{tbl:mehrprozessor_cache}.
+
+\begin{figure}[!ht]
+	\centering
+	\includegraphics[width=\textwidth-3cm]{./Bilder/CPU_Mehrprozessor.png}
+	\caption{Mehrprozessor-/Mehrkernsystem}
+	\label{fig:cpu_mehrprozessor}
+\end{figure}
+
+\begin{table}[ht]
+	\hspace*{-5mm}
+	\begin{tabular}{@{}cp{7.6cm}|cp{7.6cm}}
+		& \textbf{gemeinsamer Cache} & & \textbf{getrennter Cache} \\ \midrule
+
+		$\oplus$ & dieselben Daten für beide Kerne benötigt bedeutet nur einmaliges Einlagern im Cache (Platzvorteil).
+		& $\ominus$ & Dieselben Daten müssen ggf. mehrfach in den Caches gehalten werden.
+		\\ [4ex]
+
+		$\ominus$ & komplexer Bus mit Zugriffsprotokoll (Zeitverlust zumindest bei Zugriffskollision)
+		& $\oplus$ & einfache 1:1-Verbindungen (kein komplexes Zugriffsprotokoll)
+		\\ [2ex]
+
+		& & $\ominus$ & keine Konsistenz trotz Write-Through Strategie gewährleistet\\
+	\end{tabular}
+	\caption{Vergleich von getrennten/gemeinsamen Caches bei Mehrkernsystemen}
+	\label{tbl:mehrprozessor_cache}
+\end{table}
+
+Abhilfe für Inkonsistenz bei mehreren Caches und Mehrprozessorsystemen:
+
+\begin{itemize}[noitemsep]
+	\item gemeinsamer Cache (ungünstige Performance aufgrund eines Bus)
+	\item Snoop-Logik, \dash jeder Cache schnüffelt bei den anderen Caches bzw. beim \acs{HS}, welche Daten geschrieben wurden und invalidiert diese ggf. im eigenen Cache.
+\end{itemize}
+
+Tatsächlich haben moderne \acsp{CPU} beim L1-Cache getrennte Caches für jeden Kern und beim L3-Cache einen gemeinsamen Cache. Ob eine Snoop-Logik verwendet wird, ist davon abhängig, ob es für das Level notwendig ist oder nicht.