Re: Lock Elision / Transaction ABI discussion

[Torvald Riegel <triegel at redhat dot com>]

On Tue, 2013-09-17 at 09:08 +0200, Dominik Vogt wrote:
> Another approach would be to not reserve specific abort status
> codes but to give some of the user defined bits certain meanings.
> Given the predefined codes with Tsx, that's probably difficult to
> change now (0xff has all possible bits set).  On z that is a valid
> approach; the lowest bit already determines whether a retry may be
> useful or not (i.e. the lowest bit of the user defined abort code
> is reflected in the lowest bit of the condition code of the
> instruction).
> 
> As a matter of fact, the valid values for a user defined abort
> code with Tsx (0 to 255) are all invalid on z (256 to 2^64 - 1),
> and profiling with Haswell seems to work very differently than on
> the zEC12.  As I understand, Haswell provides hardware counters
> for profiling?  On the zEC12 we have to do the profiling in
> software (at the time being it's a gcc patch).  As a consequence
> individual abort codes may be much more important on Haswell than
> on zEC12 (where I get a program address of the abort anyway as
> a result of profiling).  Furthermore we'll end up with a platform
> specific ABI, and it will be tedious for application programmers
> to write code that is portable to multiple platforms regarding
> that ABI.  As far as I understand, while the Haswell and the zEC12
> implementations of transactional memory are very similar, other
> cpus implement it in a very different way (e.g. Power).

I don't think it's much of a problem if the ABI is platform-specific.
It will be architecture-specific anyway, as your example with the
different numeric intervals for abort codes shows.  If the HTMs are
different, there are likely to be differences in how you need to use
them anyway; for example, when to fall back to nontransactional
execution, how to do runtime tuning, etc.  If programmers don't want to
deal with these low-level aspects, they can use higher-level
abstractions: transactional language constructs such as being specified
by ISO C++ SG5, or through traditional locks and lock-based code where
the implementations use elision.

> Somewhere else Torvald asked if there is some effort by IBM to
> standardize abort codes.  I'm not completely sure, but I doubt it;
> if such an effort would be made, the person to trigger that would
> probably be me, but I'll ask the colleagues about that.

Thanks.

Torvald