Software Engineering discussion
Beautiful Code
>
Beautiful Concurrency
date
newest »
newest »
Haskell is very hard for me to read, but the code had some comment lines that helped.Software Transactional Memory was a new term for me, but I did recognize it as a database-like concept. I'm not sure how close STM is to a Java Monitor Synch concept: http://www.artima.com/insidejvm/ed2/t...
The Haskell examples certainly had a different "feel" than a Java Monitor. Maybe that was just due to my lack of understanding Haskell.
The Java Monitor is the machinery that supports the object locking available via the synchronized keyword. It is a low-level concurrency construct for supporting concurrent access to an object via multiple threads.
The Haskell examples (non-STM) show how more sophisticated multi-object and error recovery scenarios are handled using a programming model that is simpler than the Java approach.
STM allows a transaction to touch multiple objects and adds support for abort or commit so that one thread can optimistically do what it wants while another thread does the same, yet the ACID (atomicity, consistency, isolation, durability) properties hold (although not durability in the persistent written-to-media sense). To do this, STM uses the DB technique of using a log for transaction management, except this is all done to support a network of in-memory objects instead of rows in DB tables on disk.
The Haskell examples (non-STM) show how more sophisticated multi-object and error recovery scenarios are handled using a programming model that is simpler than the Java approach.
STM allows a transaction to touch multiple objects and adds support for abort or commit so that one thread can optimistically do what it wants while another thread does the same, yet the ACID (atomicity, consistency, isolation, durability) properties hold (although not durability in the persistent written-to-media sense). To do this, STM uses the DB technique of using a log for transaction management, except this is all done to support a network of in-memory objects instead of rows in DB tables on disk.
The chapter actually covers two beautiful ideas.
Haskell, as an example functional programming language, is truly beautiful. We get a little snapshot of this in this chapter, but these languages have a long learning curve and it can take some time to appreciate the elegance. I am a little ways up that curve, but in my mind the jury is still out on how generally applicable these languages are. Would I want to write a .NET or iPad application in one? Beauty and usefulness are two different notions, and they sometimes don't go together.
The second beautiful idea is Software Transactional Memory (STM). Haskell is not the only language to include this, but STM is a natural fit with functional languages. In brief, STM is an in-memory implementation of what disk-based databases have offered for decades (ACID properties). It can help make concurrency easier to implement, and this is an increasingly important thing given that processors are growing horizontally (more cores vs. more GHz).
A great reference for STM is "Parallel Programming with Transactional Memory" by Ulrich Drepper in the Communications of the ACM, 2/2009, which is free at this link:
http://portal.acm.org/citation.cfm?id...