Re: [PATCH][BZ #14417] Unlock mutex before going back to waitingfor PI mutexes

[Jeff Law <law at redhat dot com>]

On 09/30/2012 11:51 PM, Siddhesh Poyarekar wrote:
> > I would be surprised if a single branch after a syscall would be a
> > measurable performance degradation.  Not sure what the policy for this
> > is, but I'd prefer an abort or such if we get a return value we didn't
> > expect.  Also, if we get frequent spurious wake-ups, then this branch
> > is the smallest part of the overhead.
>
> I got the impression in the past that the nptl code had to be as
> trim as possible, which is why I left it out on purpose.  If the abort
> is OK in this for others, I'll put it in.
I'd go without the abort in this case -- primarily because glibc hasn't 
introduced aborts for this kind of "can't or shouldn't happen" behaviour 
as liberally as other projects (such as GCC).  I'm not aware of any in 
the hand written assembly bits, which were written presumably to be 
absolutely as fast as possible.

I wouldn't mind revisiting the overarching question of adding 
asserts/aborts for these kinds of conditions, but that would be a 
separate discussion and separate patches, IMHO.

jeff