
Transactional Memory Support for C [pdf] - vmorgulis
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1961.pdf
======
mattiemass
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
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
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
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-...](http://kukuruku.co/hub/cpp/transactional-memory-history-and-
development) 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 :)

~~~
continuational
That's not how TM is supposed to work; it should not be possible for one
atomic block to observe an uncommitted write of another atomic block. It must
act as if each atomic block acquires a single global lock, executes, and then
releases the lock so that other atomic blocks may execute. The challenge is to
emulate this without actually using a single global lock.

~~~
signa11
> That's not how TM is supposed to work; it should not be possible for one
> atomic block to observe an uncommitted write of another atomic block.

well, transactions need to be atomic w.r.t each other, but what about their
relationship to non-transactional code ? it might appear that this is just an
'implementation' detail, but, programs can contain unprotected references to
shared variables (i.e., outside transactions) without creating malignant data
races. so, both transactional and non-transactional code can refer to the same
data.

this is where the notion of strong and weak atomicity comes from, and which is
what the pseudo code was trying (probably unsuccessfully) to show.

------
lindig
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
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

