This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH 07/10] Add __pthread_set_abort_hook export
On Wed, 2013-01-16 at 19:46 +0100, Andi Kleen wrote:
> On Wed, Jan 16, 2013 at 06:42:25PM +0100, Torvald Riegel wrote:
> > On Fri, 2013-01-11 at 23:33 +0100, Andi Kleen wrote:
> > > On Fri, Jan 11, 2013 at 10:23:50PM +0100, Torvald Riegel wrote:
> > > > On Thu, 2013-01-10 at 12:19 -0800, Andi Kleen wrote:
> > > > > From: Andi Kleen <firstname.lastname@example.org>
> > > > >
> > > > > For some debugging scenarios it is useful to catch aborts. Looking
> > > > > at the abort code can be the only way to get information out of a
> > > > > memory transaction.
> > > >
> > > > If it's purely for debugging purposes through external debugging tools,
> > > > a systemtap probe or something similar might also be sufficient (or
> > > > better).
> > >
> > > It's not. Out of band monitoring is very different from in-band.
> > So what's the in-band monitoring use case?
> Transaction aware assert. Out of band monitoring is generally done with
> PMU profilers like perf using PEBS records.
>From this README:
"Normal assertations and other faults do not work inside transactions.
That is they abort the transaction and will be reexecuted. But if
the problem only happens during the transaction itself they will never
Why would this happen in critical sections that just use lock elision?
TSX doesn't expose side effects of noncommitted txns, so the only bug
(and that you'd want to catch with an assert) that I can think would are
TSX-related issues. But all correct programs cannot assume that they
can execute certain transactions anyway, so why TXN-specific assertions?
So, what's the use case for TXN_ASSERT? Do you want to let programs
assert that they do not execute in a transactional context?
Also, TXN_ASSERT is not itself setting the abort handlers. So what/who
uses them (ie, consumes the assertions), and for what?
> > And yes, what you implement is the concept of eliding locks using HW
> > help, so I'd use the hardware lock elision name coined for this concept.
> In the context of TSX HLE means XACQUIRE/XRELEASE prefixes. Since these
> are not used in the glibc implementation calling the glibc
> implementation HLE is not appropiate.
You got this backwards. For glibc names, the glibc context is primary,
not the name of the HW mechanism that might be used to implement a
certain glibc feature. For example, what would happen if we would
indeed use XACQUIRE/XRELEASE on future CPUs? Would we then rename the
(Of course, IANAL, and I haven't checked trademarks or whatever...)
> I can rename the hook __pthread_set_elision_abort_hook_np, although
> I personally think that name is too long.
lock_elision would be better. (I'd still prefer the acronym though.)
In any case, if an identifier is exposed externally, it should rather be
long than not descriptive and prone to naming collisions.