This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Lock Elision / Transaction ABI discussion
- From: Dominik Vogt <vogt at linux dot vnet dot ibm dot com>
- To: libc-alpha at sourceware dot org
- Cc: triegel at redhat dot com, andi at firstfloor dot org
- Date: Fri, 20 Sep 2013 09:59:26 +0200
- Subject: Re: Lock Elision / Transaction ABI discussion
- Authentication-results: sourceware.org; auth=none
- References: <20130916133554 dot GA20561 at linux dot vnet dot ibm dot com> <20130916135243 dot GA18073 at linux dot vnet dot ibm dot com> <87eh8o64sz dot fsf at tassilo dot jf dot intel dot com> <20130917070836 dot GB3353 at linux dot vnet dot ibm dot com> <1379405425 dot 32370 dot 5025 dot camel at triegel dot csb>
- Reply-to: libc-alpha at sourceware dot org
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, _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.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany