6 ms·

Transactional Memory Support for C [pdf]

39 points by vmorgulis 11y ago

lindig 11y ago
Admittedly, this is a sideshow: The typesetting quality of this document considerably lowered my confidence in its technical quality. It is appalling. More than 40 years after troff and more than 30 years after TeX were invented, computer science as a discipline should be able to do better. Addendum: I don't want to imply that Troff and TeX are not adequate. Quite to the contrary. This PDF from Word is so bad that it doesn't match a quality that we surpassed decades ago. And even while using Word, the typesetting could be much better.
- dmm 11y ago
  It's a word document exported as pdf: $ pdfinfo n1961.pdf Author: Michael Wong Creator: Acrobat PDFMaker 9.0 for Word Producer: Adobe PDF Library 9.0 CreationDate: Mon Sep 28 05:04:06 2015 ModDate: Mon Sep 28 05:04:23 2015 Tagged: yes UserProperties: no Suspects: no Form: none JavaScript: no Pages: 9 Encrypted: no Page size: 612 x 816.96 pts Page rot: 0 File size: 198701 bytes Optimized: yes PDF version: 1.5
- ben_bai 11y ago
  The good old days... where text documents where ".txt" I've seen pure text mails of mine getting copied into ".ppt" with horrible formatting an then getting send around by e-mail. And I just had some plain text-only questions nothing anybody would ever present.
- jhallenworld 11y ago
  I'm not that worried about it. I mean why is this not acceptable, but RFCs are acceptable? I remember there was a computer architecture journal (ACM SIGARCH?) which had articles which were photocopies of dot-matrix printouts.
mattiemass 11y ago
I'm really excited about transactional memory, particularly since Intel's RTM launched. I've played with it a bunch, and it really opens up some new kinds of programming. Seeing it in C would be awesome.
signa11 11y ago
Not sure if folks here have had a chance to look at this : http://queue.acm.org/detail.cfm?id=1454466 http://queue.acm.org/detail.cfm?id=1454466 ? Would be very interested to get your thoughts on this.
- gpderetta 11y ago
  The paper dismiss TM as not mature enough and not worth the cost. Since the paper publication (2008), HTM support was added on a few mainstream CPUs (intel, power). Also, TM is likely to be in the next C++ standard: the specification has been published as Technical Report (GCC already implements a slightly older draft) and handles many of the issues identified in the paper, in particular its interaction with non-transactional atomic operations and exceptions. Mind you, TM might still end up not being worth the trouble, but at least there is a serious ongoing effort to push it into a mainstream language. I believe that, among the authors of the paper, at least Magel Michael was involved in the C++ Transactonal Memory TR.
  - signa11 11y ago
    thanks to both gpderetta and chrisseaton for their insightful replies. as i was looking for more sources of information, i stumbled upon this: http://kukuruku.co/hub/cpp/transactional-memory-history-and-development http://kukuruku.co/hub/cpp/transactional-memory-history-and-... where we see a large number of folks trying and eventually giving up on tm both in h/w and s/w implementations e.g. sun tried adding tm support to their sparc(rock)-v9 processor, but after oracle bought them, the project was shelved for “This processor had two astonishing features: it was incredibly low and consumed plenty of energy. It was so hot that they had to hang 12 inches of cooling fans so that processor wouldn’t overheat. It would have been insane to continue this project.” to me at least, it seems that optimistic-reads with in-place pessimistic writes and automatic retries a.k.a weakly-atomic-update-in-place (raison d'être for tm) is the biggest torpedo in tm's direction. for example, assume we have : ---x---x---x---x---x---x---x---x---x bool owning_obj = false; some_obj x = new some_obj(); /* txn-0 */ atomic { owning_obj = true; } int z = x.some_value; ---x---x---x---x---x---x---x---x---x /* txn-1 */ atomic { if (!owning_obj) x.some_value = 12314; } ---x---x---x---x---x---x---x---x---x ok, so now we have a problem :), specifically : although txn-1 would rollback, because the value of owning_obj is changed, but it is too late. the other thread using x (txn-0) will see a constantly changing state. who knows what will happen next. it might be possible to have some kind of RCU semantics here, where you wait for a quiescent state to be reached, but that would be pretty complicated. may you please provide your comments ? it is all very educational :)

39 points by vmorgulis 11y ago

Admittedly, this is a sideshow: The typesetting quality of this document considerably lowered my confidence in its technical quality. It is appalling. More than 40 years after troff and more than 30 years after TeX were invented, computer science as a discipline should be able to do better. Addendum: I don't want to imply that Troff and TeX are not adequate. Quite to the contrary. This PDF from Word is so bad that it doesn't match a quality that we surpassed decades ago. And even while using Word, the typesetting could be much better.

dmm 11y ago
It's a word document exported as pdf: $ pdfinfo n1961.pdf Author: Michael Wong Creator: Acrobat PDFMaker 9.0 for Word Producer: Adobe PDF Library 9.0 CreationDate: Mon Sep 28 05:04:06 2015 ModDate: Mon Sep 28 05:04:23 2015 Tagged: yes UserProperties: no Suspects: no Form: none JavaScript: no Pages: 9 Encrypted: no Page size: 612 x 816.96 pts Page rot: 0 File size: 198701 bytes Optimized: yes PDF version: 1.5
ben_bai 11y ago
The good old days... where text documents where ".txt" I've seen pure text mails of mine getting copied into ".ppt" with horrible formatting an then getting send around by e-mail. And I just had some plain text-only questions nothing anybody would ever present.
jhallenworld 11y ago
I'm not that worried about it. I mean why is this not acceptable, but RFCs are acceptable? I remember there was a computer architecture journal (ACM SIGARCH?) which had articles which were photocopies of dot-matrix printouts.

mattiemass 11y ago

I'm really excited about transactional memory, particularly since Intel's RTM launched. I've played with it a bunch, and it really opens up some new kinds of programming. Seeing it in C would be awesome.

signa11 11y ago

Not sure if folks here have had a chance to look at this : http://queue.acm.org/detail.cfm?id=1454466 http://queue.acm.org/detail.cfm?id=1454466 ? Would be very interested to get your thoughts on this.

gpderetta 11y ago
The paper dismiss TM as not mature enough and not worth the cost. Since the paper publication (2008), HTM support was added on a few mainstream CPUs (intel, power). Also, TM is likely to be in the next C++ standard: the specification has been published as Technical Report (GCC already implements a slightly older draft) and handles many of the issues identified in the paper, in particular its interaction with non-transactional atomic operations and exceptions. Mind you, TM might still end up not being worth the trouble, but at least there is a serious ongoing effort to push it into a mainstream language. I believe that, among the authors of the paper, at least Magel Michael was involved in the C++ Transactonal Memory TR.
- signa11 11y ago
  thanks to both gpderetta and chrisseaton for their insightful replies. as i was looking for more sources of information, i stumbled upon this: http://kukuruku.co/hub/cpp/transactional-memory-history-and-development http://kukuruku.co/hub/cpp/transactional-memory-history-and-... where we see a large number of folks trying and eventually giving up on tm both in h/w and s/w implementations e.g. sun tried adding tm support to their sparc(rock)-v9 processor, but after oracle bought them, the project was shelved for “This processor had two astonishing features: it was incredibly low and consumed plenty of energy. It was so hot that they had to hang 12 inches of cooling fans so that processor wouldn’t overheat. It would have been insane to continue this project.” to me at least, it seems that optimistic-reads with in-place pessimistic writes and automatic retries a.k.a weakly-atomic-update-in-place (raison d'être for tm) is the biggest torpedo in tm's direction. for example, assume we have : ---x---x---x---x---x---x---x---x---x bool owning_obj = false; some_obj x = new some_obj(); /* txn-0 */ atomic { owning_obj = true; } int z = x.some_value; ---x---x---x---x---x---x---x---x---x /* txn-1 */ atomic { if (!owning_obj) x.some_value = 12314; } ---x---x---x---x---x---x---x---x---x ok, so now we have a problem :), specifically : although txn-1 would rollback, because the value of owning_obj is changed, but it is too late. the other thread using x (txn-0) will see a constantly changing state. who knows what will happen next. it might be possible to have some kind of RCU semantics here, where you wait for a quiescent state to be reached, but that would be pretty complicated. may you please provide your comments ? it is all very educational :)