Re: Lock Elision / Transaction ABI discussion

[Torvald Riegel <triegel at redhat dot com>]

On Fri, 2013-09-20 at 09:59 +0200, Dominik Vogt wrote:
> On Tue, Sep 17, 2013 at 10:10:25AM +0200, Torvald Riegel wrote:
> > On Tue, 2013-09-17 at 09:08 +0200, Dominik Vogt wrote:
> > > 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.
> 
> None of the Ibm software people can think of anybody who is going
> to make such an effort to standardize abort codes.
> 
> One important point that was not mentioned that because it's not
> obvious when you use transactions in "debug mode" all the time:
> While the abort status code is always available with Intel's Tsx,
> that is not true on z.  The z architecture puts this information
> into the transactional diagnostic block; a piece of memory that
> may or may not be supplied by the caller.  Since generating the
> tdb costs performance, one cannot expect that the tdb is always
> there, so the abort code is usually not accessable.

So, in essence, it might be that there are (many?) callers that aren't
interpreting the program-supplied abort code anyway.  I believe that
this would mean that those callers need to be conservative in how often
they retry the transaction anyway, because they could be executing code
that uses aborts to signal cases where it can't execute something
transactionally?

> So, _if_ we make an Abi for z, it will probably just reserve the
> abort codes 256 and 257 for temporary and persistent explicit
> aborts without any further meaning.

That would at least be sufficient I guess.