Vor kurzem war Nebenläufigkeit mit Software Transactional Memory das Thema hier im Blog. Da Nebenläufigkeit auch in modernen Softwaresystemen immer noch häufig ein schwieriges Problem und eine Quelle vieler Fehler ist, schauen wir uns heute Software Transactional Memory (kurz: STM) nochmal genauer an. Funktionale Sprache wie z.B. Haskell, Scala oder clojure bieten gute Unterstützung für STM, denn der deklarative Programmierstil und der weitgehende Verzicht auf Seiteneffekte passen gut zum STM-Paradigma.
Wir haben in dem ersten Artikel gesehen, dass STM eine Alternative zu Locks darstellt, die einfacher zu benutzen ist und bei der Probleme wie Deadlocks oder Race Conditions typischerweise nicht oder nur sehr selten auftreten. Meine tägliche Erfahrung mit STM in unserem Softwareprodukt CheckpadMED bestätigt mich immer wieder darin, dass Nebenläufigkeit mit STM eigentlich (relativ) einfach ist: man muss lediglich spezifizieren, welche Codeblöcke atomar laufen sollen, und das Laufzeitsystem stellt dann diese Atomizitätseigentschaft sicher.
Im heutigen Artikel untersuchen wir STM etwas genauer. Wir gehen dabei der Behauptung nach, die wir im ersten Artikel aufgestellt haben, nämlich dass auch Gründe der Softwarearchitektur für STM sprechen: während zwei mit Locks implementierte Programmkomponenten oftmals nicht ohne Änderung des Locking-Protokolls zu einer neuen Komponenten zusammengebaut werden können, klappt ein solcher Zusammenbau mit STM meist problemlos, ohne dass man sich über Implementierungsdetails der Komponenten Gedanken machen muss.
Weiterlesen...