Re: Lock Elision / Transaction ABI discussion

[Torvald Riegel <triegel at redhat dot com>]

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?


Torvald