[Bug nptl/15119] [arm] unnecessary busy loop in __lll_timedlock_wait on ARM

["cvs-commit at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=15119

--- Comment #3 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  6d96f5e4c0500b19d1c2f4edc37536d2bc592260 (commit)
      from  4fa262fa9e8836f2e513e3ea56797dab2d75e6de (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=6d96f5e4c0500b19d1c2f4edc37536d2bc592260

commit 6d96f5e4c0500b19d1c2f4edc37536d2bc592260
Author: Will Newton <will.newton@linaro.org>
Date:   Thu May 1 14:25:44 2014 +0100

    ARM: Remove lowlevellock.c

    lowlevellock.c for arm differs from the generic lowlevellock.c only in
    insignificant ways, so can be removed. Happily, this fixes BZ 15119
    (unnecessary busy loop in __lll_timedlock_wait on arm).

    The notable differences between the arm and generic implementations are:

    1) arm __lll_timedlock_wait has a fast path out if futex has been set
    to 0 between since the function was called. This seems unlikely to
    happen very often, so it seems at worst harmless to lose this fast
    path.

    2) Some function in arm's lowlevellock.c set futex to 2 if it was 1.
    The generic version always sets the futex to 2. As futex can only be
    0, 1 or 2 on entry into these functions, the behaviour is equivalent.
    (If the futex manages to be 0 on entry then we've just lost another
    unlikely fast path out.)

    There are no test suite regressions.

    Note that hppa and sparc also have their own lowlevellock.c. I believe
    hppa can also be removed, so I'll send a separate patch for that
    shortly. sparc's seems to be genuinely needed as it uses a different
    locking structure.

    Also note that the analysis at
    https://sourceware.org/ml/libc-ports/2013-02/msg00021.html indicates a
    further locking performance bug to fix - I've got a partial patch for
    that which I can submit once I've finished testing.

    2014-05-01  Bernard Ogden <bernie.ogden@linaro.org>

        [BZ #15119]
        * sysdeps/unix/sysv/linux/arm/nptl/lowlevellock.c: Remove file.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog                                       |    6 +
 sysdeps/unix/sysv/linux/arm/nptl/lowlevellock.c |  132 -----------------------
 2 files changed, 6 insertions(+), 132 deletions(-)
 delete mode 100644 sysdeps/unix/sysv/linux/arm/nptl/lowlevellock.c

-- 
You are receiving this mail because:
You are on the CC list for the bug.