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: libc-alpha at sourceware dot org, triegel at redhat dot com, andi at firstfloor dot org
- Date: Wed, 18 Sep 2013 00:02:45 +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> <20130916161538 dot GY18242 at two dot firstfloor dot org> <20130917064942 dot GA3353 at linux dot vnet dot ibm dot com>
On Tue, Sep 17, 2013 at 08:49:42AM +0200, Dominik Vogt wrote:
> On Mon, Sep 16, 2013 at 06:15:38PM +0200, Andi Kleen wrote:
> > 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.
>
> Does that mean, if you use the Xabort instruction, you have no way
> of controlling bit 1 of the abort status (the retry bit)?
That is correct, it's always 0.
-Andi