Transactional memory

By: Paul A. Clayton (paaronclayton.delete@this.gmail.com), September 23, 2010 6:30 am
Room: Moderated Discussions
Linus Torvalds (torvalds@linux-foundation.org) on 9/21/10 wrote:
---------------------------
[snip]
>I think you've bought into the hype too much.

Perhaps.

>In theory it works the way you say. In practice? Not
>so much. Because of the limits on how big a transaction can
>be, you end up having to have fall-back cases etc, or can
>only use it for trivial cases where you know you won't be
>overflowing any transaction sizes.

I suspect in practice is rather difficult to evaluate at
this point. As far as I know, the only hardware TM
systems have been the Sun-internal (never sold--did anyone
outside of Sun even get to play with early prototypes?)
Rock and Azul Systems implementation--which has entry-price
and non-open development issues.

One does need software support to handle transaction
failures, and hardware needs to provide information about
why the transaction failed so the software can decide
whether to retry (and with how much delay), queue the
transaction, use a locking mechanism, or something else.
(Ideally, the system would allow this profile information
to be fed back to the developer/development system.)
Overflow is only one possible reason for failure. (I am
inclined to support less predictable overflow--e.g.,
non-fully associative records, sharing resources among
multiple threads, etc.--for the sake of supporting larger
average transactions even though it makes things more
difficult for software.)

(When the transaction can contain but not include--i.e.,
track--an unlimited number of memory accesses, some large
transactions can be supported through indirection. I do
not know how much of the burden of setting up and managing
such indirection could be taken off the programmer, but I
am somewhat optimistic that with a very good development
system and a smallish number of highly-skilled programmers
would allow a significant advancement in parallel
programming.)

I do not know how common the 'trivial' cases are or how
difficult it would be for a development system to
identify extremely likely/certain transaction failures (and
generate a compile-time error) and very likely failures
(and generate a compile-time warning). I would think that
just making the relatively easy cases relatively easy and
not making the hard cases much (if any) harder would be a
significant win over current methods.

>I have yet to hear of anybody that actually does the
>whole transactional memory thing well.

I would think that hardware support makes the 'trivial'
cases a lot easier and the less trivial cases (which
presumably already have significant overhead anyway) can
be handled in a simpler, less performance-optimized
manner (with the hope that they are also less common).

(Note: I did not imply that the difficulty of identifying
critical sections would disappear. I would think that
large critical sections are more difficult not only because
of the fine-grained versus coarse-grained locking but
because of partial sharing among the active collections of
locks. Simple hardware transactional memory does not help
in that case--though it might help in identifying conflicts.
Some of the proposals for complex hardware could help in
interleaving actions within transactions, but I receive the
impression that such mechanisms are currently poorly
understood, expensive to implement, and are still not
'pixie dust'.)


Paul A. Clayton
just a technophile
< Previous Post in ThreadNext Post in Thread >
TopicPosted ByDate
T3 announcedMax2010/09/21 03:42 AM
  T3 announcedsomeone2010/09/21 04:53 AM
    T3 announcedanon2010/09/21 05:05 AM
      T3 announcedlurker2010/09/21 06:11 AM
      T3 announcedJesper Frimann2010/09/21 06:21 AM
      T3 announcedPhil2010/09/21 11:59 PM
        T3 announcedMichael S2010/09/22 05:16 AM
  T3 announcedLinus Torvalds2010/09/21 06:15 AM
    T3 announcedanon2010/09/21 08:31 AM
      Transactional memory Paul A. Clayton2010/09/21 09:52 AM
        Transactional memory Linus Torvalds2010/09/21 11:21 AM
          Transactional memory Paul A. Clayton2010/09/23 06:30 AM
            Transactional memory Linus Torvalds2010/09/23 07:01 AM
              Transactional memory David Kanter2010/09/23 11:05 PM
                Transactional memory Linus Torvalds2010/09/24 06:59 AM
                  Transactional memory David Kanter2010/09/25 08:27 AM
                    'dynamic fallback'?Paul A. Clayton2010/09/25 10:28 AM
                      'dynamic fallback'?Linus Torvalds2010/09/25 12:23 PM
                        'dynamic fallback'?blaine2010/09/25 01:16 PM
                Cliff Click Jr. on Azul's HTMPaul A. Clayton2010/09/24 01:19 PM
              Transactional memory Foo_2010/09/24 02:08 AM
    T3 announcedblaine2010/09/21 10:43 AM
      no news from FujitsuMax2010/09/21 09:37 PM
Reply to this Topic
Name:
Email:
Topic:
Body: No Text
How do you spell avocado?