4 ms·

GCC supports code generation that will call into several different software transactional memory (STM) engines. It's not difficult to write your own engine that

GCC supports code generation that will call into several different software transactional memory (STM) engines. It's not difficult to write your own engine that is called instead of a default version. What this basically does is generate multiple versions of functions that can be called both in and not in a transaction. Functions that may be called in a transaction have to be side-effect free (i.e., no system calls, recursively). The modified functions run code for each line of memory read or written so the STM engine can decide what to do with it (e.g., reads can be redirected to other locations, writes can be used to dirty memory or redirected to a scratch location). There are different trade-offs for efficiency, conflicts, etc. For instance, if each transaction begin just started with a global exclusive lock it would be correct, simple, and you'd never get conflicts, but just serializes everything. There are trade-offs. Languages with more rigid semantics and a propensity towards immutability would require less annotation. The GCC version generates these invocations for engine functions on most loads and stores. As you'd imagine, it's pretty expensive as is and basically is not used as a generic method of concurrency control for this reason.

anonymousDan 4y ago
Interesting, do you have a link to the documentation for this (or even a paper describing the design)? Does Clang/LLVM have something similar? I wonder would adding STM to Rust be more practical in terms of performance (or does the question even make sense given it already guarantees data race freedom)?
- arghnoname 4y ago
  There's an Intel ABI specification that GCC closely follows. The gcc implementation is called libitm and their specification is just listed as a diff of intel's specification. Here is gcc's doc on libitm https://gcc.gnu.org/onlinedocs/libitm/ https://gcc.gnu.org/onlinedocs/libitm/ Here is intel's document (much more useful): https://gcc.gnu.org/wiki/TransactionalMemory?action=AttachFile&do=get&target=Intel-TM-ABI-1_1_20060506.pdf https://gcc.gnu.org/wiki/TransactionalMemory?action=AttachFi... I'm not sure what the support story is like on clang.
- gpderetta 4y ago
  A few years ago it seemed that every cpu architecture was going to get hardware transactional memory acceleration. SPARC had it, POWER had it, even Intel added it. A transactional memory proposal for C++ made it into a Technical Report, it got implemented in GCC and it seemed to be ready to be merged into the standard. Then I'm not sure what happened, things seem to have run out of steam, Intel never managed to make its HTM to work well and it unofficially deprecated it and generally TM went out of fashion. The TR is still there and gets minor updates, but I haven't heard about any push to merge it.
  - jdougan 4y ago
    As I understand it, a bunch of people became less convinced of TM's usefulness eg. http://joeduffyblog.com/2010/01/03/a-brief-retrospective-on-transactional-memory/ http://joeduffyblog.com/2010/01/03/a-brief-retrospective-on-...
    - anonymousDan 4y ago
      Thanks a lot for that, very interesting perspective (particularly the challenges with unbounded transactions and nontransactional I/O). It makes me wonder (i) whether bounded transactions were also found to be too hard to use (given restrictions on transaction sizes) (ii) what has replaced STM in terms of better fine-grained concurrency control abstractions (if anything). Maybe better type system support through new languages (e.g. Rust)?
      - jdougan 4y ago
        I am not familiar with any details, but the haskellians seem to still be working with STM. At least there are a bunch on talks online about it. I had spent most of the 90s working with transactional systems and while they are useful and powerful, they aren't magic and require awareness to keep from making errors. Joe Duffy wasn't wrong when he says those problems are well known. The solutions normally are either Don't Do That Then, or managing the policy details and logic yourself, which wasn't giving them the easy concurrency they were trying for. Edit: He has a followup post at http://joeduffyblog.com/2010/05/16/more-thoughts-on-transactional-memory/ http://joeduffyblog.com/2010/05/16/more-thoughts-on-transact...

anonymousDan 4y ago

Interesting, do you have a link to the documentation for this (or even a paper describing the design)? Does Clang/LLVM have something similar? I wonder would adding STM to Rust be more practical in terms of performance (or does the question even make sense given it already guarantees data race freedom)?

arghnoname 4y ago
There's an Intel ABI specification that GCC closely follows. The gcc implementation is called libitm and their specification is just listed as a diff of intel's specification. Here is gcc's doc on libitm https://gcc.gnu.org/onlinedocs/libitm/ https://gcc.gnu.org/onlinedocs/libitm/ Here is intel's document (much more useful): https://gcc.gnu.org/wiki/TransactionalMemory?action=AttachFile&do=get&target=Intel-TM-ABI-1_1_20060506.pdf https://gcc.gnu.org/wiki/TransactionalMemory?action=AttachFi... I'm not sure what the support story is like on clang.
gpderetta 4y ago
A few years ago it seemed that every cpu architecture was going to get hardware transactional memory acceleration. SPARC had it, POWER had it, even Intel added it. A transactional memory proposal for C++ made it into a Technical Report, it got implemented in GCC and it seemed to be ready to be merged into the standard. Then I'm not sure what happened, things seem to have run out of steam, Intel never managed to make its HTM to work well and it unofficially deprecated it and generally TM went out of fashion. The TR is still there and gets minor updates, but I haven't heard about any push to merge it.
- jdougan 4y ago
  As I understand it, a bunch of people became less convinced of TM's usefulness eg. http://joeduffyblog.com/2010/01/03/a-brief-retrospective-on-transactional-memory/ http://joeduffyblog.com/2010/01/03/a-brief-retrospective-on-...
  - anonymousDan 4y ago
    Thanks a lot for that, very interesting perspective (particularly the challenges with unbounded transactions and nontransactional I/O). It makes me wonder (i) whether bounded transactions were also found to be too hard to use (given restrictions on transaction sizes) (ii) what has replaced STM in terms of better fine-grained concurrency control abstractions (if anything). Maybe better type system support through new languages (e.g. Rust)?
    - jdougan 4y ago
      I am not familiar with any details, but the haskellians seem to still be working with STM. At least there are a bunch on talks online about it. I had spent most of the 90s working with transactional systems and while they are useful and powerful, they aren't magic and require awareness to keep from making errors. Joe Duffy wasn't wrong when he says those problems are well known. The solutions normally are either Don't Do That Then, or managing the policy details and logic yourself, which wasn't giving them the easy concurrency they were trying for. Edit: He has a followup post at http://joeduffyblog.com/2010/05/16/more-thoughts-on-transactional-memory/ http://joeduffyblog.com/2010/05/16/more-thoughts-on-transact...