This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Lock Elision / Transaction ABI discussion
- From: Andi Kleen <andi at firstfloor dot org>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: libc-alpha at sourceware dot org, andi at firstfloor dot org, konrad dot lai at gmail dot com
- Date: Mon, 16 Sep 2013 18:15:38 +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> <1379343629 dot 32370 dot 4403 dot camel at triegel dot csb>
On Mon, Sep 16, 2013 at 05:00:29PM +0200, Torvald Riegel wrote:
> On Mon, 2013-09-16 at 15:52 +0200, Dominik Vogt wrote:
> > One concern I have with a glibc-only-ABI is that abort codes are
> > infectious. If you have libraries libfoo and libbar that both
> > use explicit abort codes, they need to know about each other even
> > if the developers are not aware of this. The explicit abort codes
> > of libfoo pollute the abort code range that is available to libbar
> > or glibc, and all the libraries need to know that.
>
> Agreed. That's why Andi suggested the x86_64 ABI as where the abort
> codes should be defined (ie, to make it part of the ABI that also
> defines calling conventions and such).
>
> > So, if glibc reserves some abort codes in an ABI, that only solves
> > the resource conflict locally. Other variants of a c library need
> > to adhere to the same rules as glibc. Furthermore, while z has
> > 64-bit abort codes, Intel's Tsx has only 8-bit user define abort
> > status codes, so available space is scarce.
>
> I agree that available space might be scarce, but I also don't see too
> many things we'd need to communicate to the outermost transaction. We'd
> need one code for a definitive abort (ie, can never succeed with
> transactional execution as in the trylock case), one for a temporary
> obstacle like a busy lock. We might want to distinguish the detailed
> cause for each of the two, but right now I can't really see the need for
> more. Do you have further abort reasons in mind that we'd need codes
> for?
The Intel SOM currently has three:
_XABORT_LOCK_BUSY 0xff lock busy
_XABORT_ISLOCKED 0xfe lock is locked (not in pthread, but used elsewhere)
_XABORT_TRYLOCK 0xfd nested trylock
0xf0..0xfc reserved
I was considering to add a fourth:
_XABORT_TEMPORARY 0xfc temporary failure, do not adapt
e.g. to add to the dynamic linker, which currently aborts, to prevent
useless adaptation at program startup.
In theory it would be also possible to reserve more, e.g. a range
separating retryable failures from non retryable. May be too complex
though.
-Andi