3

Just found out that Intel processors now have Transactional Memory support !!!! I learned about Transactional operations in my dB/OS class, it is a very simple concept: entire operation is executed or nothing gets executed.

How is programming under new Transactional Mem. model is different from Multithreaded model that uses locks and mutexes ? Does it mean that we will be getting rid of locks and mutexes ?

  • checkout haskell STM module – Bryan Chen Nov 18 '13 at 4:06
3

Transactional Memory (TM) programming really has two elements that need to be discussed: productivity and performance.

Productivity

Compared to locks, Transactional Memory can be considered a higher-level access-control construct. The difference is akin to imperative programming vs declarative.

From a programmer's standpoint, TM is supposed to allow you to declare what needs to be executed atomically, rather than providing instructions (in the forms of locking code) on how the atomic execution should be done.

This comes with a number of promised benefits compared to locking -- easier reasoning, composability, deadlock-freedom.

Performance

Compared to locks, TM is (supposed to be --- implementations can vary here!) an optimistic access-control construct, as opposed to the pessimism of locks. The general idea of TM is that instead of requiring mutual exclusion from an atomic region, as you would with locks, the system allows multiple threads to enter the atomic region.

By tracking the state changes, and monitoring for the possibility of data races, in the case where a race does not occur, the system will allow the threads to commit. Otherwise, at least one transaction will be aborted and re-started. In the case where conflict is rare, this can be a substantial performance gain.

Caveats

Like all real systems, there's a list of caveats as long as my arm. Here's a partial set:

  • In an HTM, you need to worry about transactions which can't be committed --- illegal opcodes, too much state for the system to handle, etc. Which means you need a fallback path.
  • How to deal with atomic IO operations?
  • Performance goes up if conflict is rare --- but what about if it's not? Performance goes down, by wasting work retrying again and again.
  • How do you cooperate between threads using TM instead of locks?
| improve this answer | |
  • IBM's zArchitecture (S/360 mainframe descendant) includes "constrained transactions" which (if valid--the constrained aspect) do not require a fallback path. Intel's Hardware Lock Elision naturally includes its own fallback path since it is speculating that the locked section can be executed as a transaction. (There also have been proposals to use TM for runahead prefetching advantages which could compensate for some abort/retry overhead. Conflict prediction is another way to reduce wasted work.) – Paul A. Clayton Feb 18 '14 at 3:43
  • @PaulA.Clayton Good point on constrained transactions / HLE. Could you elaborate on conflict prediction a bit? Did you mean a software predictor or a HW predictor? – Matthew G. Feb 18 '14 at 14:47
  • I meant a hw predictor (not currently done); with HLE, a hw predictor could avoid tx overhead by not trying a tx or retry (HLE currently uses the lock after 1st failure). The abort handler effectively must use software prediction to guess whether the tx should be retried; prediction can be sophisticated (considering tx size, scope of lock [estimate lock contention and impact of its serialization], etc.) or simple (e.g., retry twice). – Paul A. Clayton Feb 18 '14 at 21:40
  • Ah; OK. Glad to know we're on the same page. I was curious, as I'm writing my thesis on precisely this topic. – Matthew G. Feb 18 '14 at 21:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.