This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 3/6] Use XEND when a lock is busy in an elision attempt.
- From: Torvald Riegel <triegel at redhat dot com>
- To: libc-alpha at sourceware dot org
- Date: Wed, 11 Sep 2013 17:47:19 +0200
- Subject: Re: [PATCH 3/6] Use XEND when a lock is busy in an elision attempt.
- Authentication-results: sourceware.org; auth=none
- References: <20130902075228 dot GA4792 at linux dot vnet dot ibm dot com> <20130902080214 dot GC4997 at linux dot vnet dot ibm dot com>
On Mon, 2013-09-02 at 10:02 +0200, Dominik Vogt wrote:
> The patch replaces XABORT with XEND in case a transaction needs to be manually
> aborted because the futex is locked when we have opened a transaction. This
> approach is less invasive than aborting because it keeps outer transactions
> intact. The transaction may still abort later, when the futex is acquired.
It *will* abort later. Always. It saw an acquired lock, so it can't
make progress until the lock is released, but once it's released, the
release will abort the transaction. It could spin nontransactionally on
the lock when this is the outermost transaction (ie, not nested), but
the same will happen with the abort because then we're getting our own
abort code.
> Another advantage is that we do not throw our private abort code at the creator
> of the outermost transaction.
This might be an advantage, but whether it is is determined by the wider
discussion around the "abort code ABI". I think we should find
consensus there first, and then see whether we need to do something (and
potentially do different things on Intel and z).