public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug nptl/15215] New: Unify pthread_once implementations.
@ 2013-02-28 19:59 carlos at redhat dot com
  2013-05-24 21:48 ` [Bug nptl/15215] " carlos at redhat dot com
                   ` (6 more replies)
  0 siblings, 7 replies; 8+ messages in thread
From: carlos at redhat dot com @ 2013-02-28 19:59 UTC (permalink / raw)
  To: glibc-bugs

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.


^ permalink raw reply	[flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-10-31 21:22 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-02-28 19:59 [Bug nptl/15215] New: Unify pthread_once implementations carlos at redhat dot com
2013-05-24 21:48 ` [Bug nptl/15215] " carlos at redhat dot com
2013-05-24 21:48 ` carlos at redhat dot com
2014-04-11 14:04 ` cvs-commit at gcc dot gnu.org
2014-06-13 18:46 ` fweimer at redhat dot com
2014-10-20 16:26 ` cvs-commit at gcc dot gnu.org
2014-10-20 19:37 ` triegel at redhat dot com
2014-10-31 21:22 ` cvs-commit at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).