This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Update on freeze status of glibc 2.18?


On Thu, 2013-06-20 at 16:09 +0200, Andi Kleen wrote:
> If you're looking for consensus, there's no consensus from me
> for the DEFAULT != NORMAL proposal. Please don't discuss 
> it like there is. In fact I totally object to it.

First of all, let's remind ourselves that DEFAULT != NORMAL does *not*
disallow anything that you proposed.  It allows us to do just some parts
of what you proposed, but it doesn't prevent all the other parts.  So
why do you object?  Because it enables a possibility to do just parts of
what you proposed?

If everything you proposed is right for the project, we can still do it.
But it seems to me that currently, we don't have consensus on your
patches as they stand today; see Roland's requirements and my comments,
for example.  So, why can't we just go forward with what we hopefully
could agree on, and deal with everything else later as soon as we have
consensus?

If we don't do the DEFAULT != NORMAL split, we can do very little
according to Roland's requirements.  In particular, there won't be any
elision for default mutexes, irrespective of whether we have a
recompiled or old binary.  We could use elision for non-nested locks
(i.e., for critical sections that aren't themselves nested within
critical-sections that use elisions) -- but that's a severe limitation,
and you said you don't want that either.

> As I explained earlier even with elision there will be eventually
> deadlocks for such programs, just not all the time.
> So the "deadlock requirement" is mostly followed.

I suppose you prefer your OS/browser/... to be "mostly correct", too? :)

> I think the disadvantages (disabling elision for all programs)

That's not a consequence, and you know that, so don't say that.  With
the DEFAULT != NORMAL split, we don't disable elision for all programs
(default-type mutexes in newly compiled applications will be able to use
elision).

> totally outweight the advantages (do something that is unlikely
> to affect any real program)

How do you know that's the case?  Rich has given convincing examples how
deadlock-on-relock could be used in a correct program (see the
guidelines, and the email discussion).  The standard is crystal-clear
regarding this requirement.  If you think that there are no such
programs, it would be you who has to prove this, sorry.

> How many programs do you have deadlocking and it's not a bug?

Rich has given correct examples.  At first I thought that it would be
unlikely that there can be correct programs, but his examples are
convincing, notably because deadlocked threads can still handle signals,
and they don't stop a program from shutting down, so fail-stop behavior
could be an intended effect by a program.

Whether the programs I know do use this behavior or not is irrelevant,
obviously because I can't ever know about all programs, nor even about
most of them.

> From my point (and why I did this glibc elision project) the main
> advantage of enabling elision in pthread is working with existing
> programs and binaries.  If that is broken, and every application
> would have to be manually modified, the value for me is gone.

Specify "gone": Are you saying that it's of no value to you if we can
enable elision for applications that are freshly compiled?  Or do you
want to say that the value for you is less?

> The point of releasing it to users for testing would be also moot because
> the testing coverage would be very limited if it's not enabled.

How much testing do you think you will get when we can't enable it by
default in distributions (see Roland's requirements) vs. when we can
enable it by default (i.e., when we do the DEFAULT != NORMAL split)?

> If everything would need to be modified it alo doesn't make a lot of sense
> to use pthread locks at all, but a more modern optimized and less overhead
> locking interface.

That actually argues for the DEFAULT != NORMAL split, because then we
don't change semantics and elision is transparent to applications from
the perspective of correctness.

Torvald


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]