Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 6 Jul 2002 13:25:56 -0700 (PDT)
From:      John Polstra <jdp@FreeBSD.org>
To:        cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   cvs commit: src/libexec/rtld-elf/alpha lockdflt.c src/libexec/rtld-elf/i386 lockdflt.c src/libexec/rtld-elf/ia64 lockdflt.c src/libexec/rtld-elf/sparc64 lockdflt.c
Message-ID:  <200207062025.g66KPuAW052156@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
jdp         2002/07/06 13:25:56 PDT

  Modified files:
    libexec/rtld-elf/alpha lockdflt.c 
    libexec/rtld-elf/i386 lockdflt.c 
    libexec/rtld-elf/ia64 lockdflt.c 
    libexec/rtld-elf/sparc64 lockdflt.c 
  Log:
  Remove the nanosleep calls from the spin loops in the locking code.
  They provided little benefit (if any) and they caused some problems
  in OpenOffice, at least in post-KSE -current and perhaps in other
  environments too.  The nanosleep calls prevented the profiling timer
  from advancing during the spinloops, thereby preventing the thread
  scheduler from ever pre-empting the spinning thread.  Alexander
  Kabaev diagnosed this problem, Martin Blapp helped with testing,
  and Matt Dillon provided some helpful suggestions.
  
  This is a short-term fix for a larger problem.  The use of spinlocking
  isn't guaranteed to work in all cases.  For example, if the spinning
  thread has higher priority than all other threads, it may never be
  pre-empted, and the thread holding the lock may never progress far
  enough to release the lock.  On the other hand, spinlocking is the
  only locking that can work with an arbitrary unknown threads package.
  
  I have some ideas for a much better fix in the longer term.  It
  would eliminate all locking inside the dynamic linker by making it
  safe for symbol lookups and lazy binding to proceed in parallel
  with a call to dlopen or dlclose.  This means that the only mutual
  exclusion needed would be to prevent multiple simultaneous calls
  to dlopen and/or dlclose.  That mutual exclusion could be put into
  the native pthreads library.  Applications using foreign threads
  packages would have to make their own arrangements to ensure that
  they did not have multiple threads in dlopen and/or dlclose -- a
  reasonable requirement in my opinion.
  
  MFC after:      3 days
  
  Revision  Changes    Path
  1.7       +2 -9      src/libexec/rtld-elf/alpha/lockdflt.c
  1.8       +2 -9      src/libexec/rtld-elf/i386/lockdflt.c
  1.2       +1 -8      src/libexec/rtld-elf/ia64/lockdflt.c
  1.2       +1 -8      src/libexec/rtld-elf/sparc64/lockdflt.c

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200207062025.g66KPuAW052156>