From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15549 invoked by alias); 28 Feb 2013 19:59:41 -0000 Received: (qmail 15460 invoked by uid 48); 28 Feb 2013 19:59:19 -0000 From: "carlos at redhat dot com" To: glibc-bugs@sourceware.org Subject: [Bug nptl/15215] New: Unify pthread_once implementations. Date: Thu, 28 Feb 2013 19:59:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: nptl X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: carlos at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2013-02/txt/msg00164.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=15215 Bug #: 15215 Summary: Unify pthread_once implementations. Product: glibc Version: unspecified Status: NEW Severity: normal Priority: P2 Component: nptl AssignedTo: unassigned@sourceware.org ReportedBy: carlos@redhat.com CC: drepper.fsp@gmail.com Classification: Unclassified At present we have several different algorithms for implementing the core of pthread_once. The following machines share one implementation, call this I1: ports/sysdeps/unix/sysv/linux/hppa/nptl/pthread_once.c ports/sysdeps/unix/sysv/linux/ia64/nptl/pthread_once.c ports/sysdeps/unix/sysv/linux/mips/nptl/pthread_once.c ports/sysdeps/unix/sysv/linux/tile/nptl/pthread_once.c nptl/sysdeps/unix/sysv/linux/sparc/pthread_once.c The following machines share another implementation, call this I2: ports/sysdeps/unix/sysv/linux/m68k/nptl/pthread_once.c ports/sysdeps/unix/sysv/linux/arm/nptl/pthread_once.c ports/sysdeps/unix/sysv/linux/aarch64/nptl/pthread_once.c The following machines have custom implementations: nptl/sysdeps/unix/sysv/linux/sh/pthread_once.S nptl/sysdeps/unix/sysv/linux/i386/pthread_once.S nptl/sysdeps/unix/sysv/linux/x86_64/pthread_once.S nptl/sysdeps/unix/sysv/linux/powerpc/pthread_once.c nptl/sysdeps/unix/sysv/linux/s390/pthread_once.c ports/sysdeps/unix/sysv/linux/alpha/nptl/pthread_once.c (a) Verify I1 is functionally equivalent to I2. - Someone should verify that the algorithm used in I1 is equivalent to I2. - If I1 is not equivalent to I2 then the algorithm should be fixed one way or the other to produce a functioning single implementation called IC. Do not cleanup any of the magic numbers yet since that's (c). - Post analysis and patch (if you changed a representative implementation) to libc-alpha@sourceware.org and libc-ports@sourceware.org and suggest (b). Notes: - It would appear that in I2 the setting of once_control via: "*once_control = __fork_generation | 2;" may not have the release semantics required by the earlier "atomic_compare_and_exchange_val_acq (once_control, newval, oldval)". This means I2 is not actually safe for systems that have weakly ordered memory writes. (b) Use IC for all machines that do not have custom implementations. - Place IC in nptl/sysdeps/unix/sysv/linux/pthread_once.c - Remove: ports/sysdeps/unix/sysv/linux/hppa/nptl/pthread_once.c ports/sysdeps/unix/sysv/linux/ia64/nptl/pthread_once.c ports/sysdeps/unix/sysv/linux/mips/nptl/pthread_once.c ports/sysdeps/unix/sysv/linux/tile/nptl/pthread_once.c nptl/sysdeps/unix/sysv/linux/sparc/pthread_once.c ports/sysdeps/unix/sysv/linux/m68k/nptl/pthread_once.c ports/sysdeps/unix/sysv/linux/arm/nptl/pthread_once.c ports/sysdeps/unix/sysv/linux/aarch64/nptl/pthread_once.c The builds will fall back to using the newly installed IC. - Post patch to libc-alpha@sourceware.org and libc-ports@sourceware.org, garner consensus, and checkin changes. (c) Cleanup IC. - We magically add +4 in nptl/sysdeps/unix/sysv/linux/fork.c to the fork generation counter, that's simply to avoid the low-two bits which we use in control object to indicate done running init_routine (bit 2 set) or running init_routine (bit 1 set). We should use a macro here like __PTHREAD_ONCE_FORK_GEN and define it in nptl/pthreadP.h. - Similarly the IC should use: /* Used by pthread_once and fork coordination. */ #define __PTHREAD_ONCE_RUN 1 /* Running the initializer. */ #define __PTHREAD_ONCE_DONE 2 /* Initializer done running. */ #define __PTHREAD_ONCE_MASK 3 /* Status bit mask. */ instead of the magic & 2, or | 1, etc, that appear in the implementation. - Get rid of the `& -4' magic, we all know this is actually `~(__PTHREAD_ONCE_FORK_GEN - 1)' which makes a lot more sense to most people and generates the same code. - Make sure that the atomic update to the control object has the correct semantics e.g. release. (d) Review i386 and x86_64 implementations. - Review: nptl/sysdeps/unix/sysv/linux/i386/pthread_once.S nptl/sysdeps/unix/sysv/linux/x86_64/pthread_once.S - How do those compare to IC? - Try compiling IC for i386 and x86_64 by simply removing the assembly implementation and examine the generated assembly to see if it's any better or the same as the custom assembly versions. - Post any interesting findings to libc-alpha@sourceware.org. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.