Re: Lock Elision / Transaction ABI discussion

[Dominik Vogt <vogt at linux dot vnet dot ibm dot com>]

On Fri, Sep 20, 2013 at 04:56:38PM +0200, Torvald Riegel wrote:
> 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?

A caller that does not request a tdb wouldn't even know whether an
abort was caused by an interrupt, the user, a resource conflict
etc.  The only information is whether whoever generated the abort
thinks a retry could be worthwhile (condition code 2) or not (1 or
3).

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany