Re: [PATCH 03/10] Add external interface changes: new lock typesfor pthread_mutex_t

[Torvald Riegel <triegel at redhat dot com>]

On Thu, 2013-01-24 at 17:53 +0100, Andi Kleen wrote:
> I already wrote extensively on the topic earlier. I don't have anything more 
> to say. It's hard to "prove" that any approach is perfect in advance,
> the only good test is time. I believe my approach has a good chance
> to work, based on my experiences so far.

I've never asked you to prove that what you proposed is perfect in
advance, but I objected to adding (ABI-changing) features for which we
do not have enough confidence that they provide benefit in the long
term.

Thus, the point is not that something is not perfect, but instead how we
ensure that we can manage including something imperfect at low risk.  A
requirement for this is that we (as in "we, the project") collectively
understand the issues at hand, the trade-offs, and why we did things in
a certain way.  It is, of course, also a way to do a sanity check of
what you propose -- not because I doubt your engineering skills, but
just because we do want to review code and because approaches and people
aren't perfect.  IMO, it would also be good if pieces in glibc are
understood by more than one person, even if this is just done to pass
the "bus test".

I understand that in this particular case, it's harder to discuss some
of the patch's aspects because we can't discuss performance in detail,
for example.  That's why some of the questions may *seem* to be vague,
and that might also be true for the answers you can give.  But I think
we can deal with that.

> If you believe you have a better approach for something please send
> patches.

This isn't a competition about whose person's patch gets accepted first.
Even if there were other proposals, we'd still have to discuss them in
the very same way.

The code itself is not the tricky thing here, I believe.  Instead, it's
which semantics we want to provide to programmers (think trylock), at
which granularity to offer tuning (per-process? per-lock? per critical
section?), whether lock elision can be enabled by default (without
requiring tuning), and how we can deploy and evolve the elision
implementation over time.

Just take the support assertions in transaction code as an example.
Both the abort hooks you proposed and the early commit that I proposed
can be done with almost trivial bits of code -- but the implications of
both approaches, and why they might work or not, are not trivial.  We
didn't discover the early commit option until after we discussed the use
cases you had in mind, TSX properties in current implementations, etc.
Thus, these discussions were useful, weren't straw man discussions at
all as you suggested earlier, and they helped us end up with a solution
(early commit) that both of us like better.

I don't see why the rest of the elision support would not benefit from a
similar discussion.

I'll try to summarize the design options and trade-offs around elision
in another email, but I don't yet know when I'll find enough time for
that.


Torvald