(S)TM

http://www.theregister.co.uk/2008/07/28/sun_dziuba_tm/

Very, very, crude language, but I'm excited that something I learned about on the side while learning Haskell (or trying to, because I couldn't figure out Monads well enough) is probably coming to hardware!

STM (Software Transactional Memory) was a really nice concept that essentially does to threading and concurrency what commit buffers and ACID properties do to database programming.  You know the database engine will take care of concurrency in database transactions, right?  STM systems will do the same for threading, except Sun is now talking about HTM (Hardware TM) and HyTM( Hybrid TM).  Cool!

STM is based on the premise that you mark out sections that are supposed to be atomic -- that's the "A" in ACID, in case you forgot -- and the back-end system will ensure that either *all* of that will happen or none of that will happen (it'll be rolled back).  What the system does is keep track of every variable you *read* and log every write you make inside the atomic block.

When you exit the atomic block, it double checks every variable you *read* to make sure it is still the same.  If they are all exactly the same, it means that none of the other threads did anything that would have conflicted with your data, so your "transaction" is committed.

However, if any of the variables you read inside the block have changed, it has to roll-back your "transaction" and maybe re-try.

In other words, optimistic concurrency control.  (Curiously, most modern Version Control Systems are also based on the same idea... go figure!)  Maybe it's time to re-start my aborted attempt at learning Haskell...

PS:  And this bit is absolutely priceless:

What I would have learned had I been more dedicated to my education were the two fundamental facts about multi-threading with locks:

• 1. You're going to fsck it up.
• 2. If you think that you haven't fscked it up, you have. You just don't know it yet.