BSD Commit Log Search

   pthread_cancel(3): Rework.

   Make pthread_setcancelstate(3) async-signal-safe.  (As a side effect,
   this also makes pthread_setcanceltype(3) async-signal-safe, although
   that is not required.)

   PR lib/59134: POSIX-1.2024: pthread_setcancelstate must be
   async-signal-safe

   libpthread: Move namespacing include to top of .c files.

   Stuff like libc's namespace.h, or atomic_op_namespace.h, which does
   namespacing tricks like `#define atomic_cas_uint _atomic_cas_uint',
   has to go at the top of each .c file.  If it goes in the middle, it
   might be too late to affect the declarations, and result in compile
   errors.

   I tripped over this by including <sys/atomic.h> in mips
   <machine/lock.h>.

   (Maybe we should create a new pthread_namespace.h file for the
   purpose, but this'll do for now.)

   Another bug.  The CAS loop in pthread_cond_signal() could race against the
   thread it is trying to awake.  The thread could exit the condvar and then
   reinsert itself at the head of the list with a new waiter behind it.  It's
   likely possible to fix this in a way that's wait-free but for now just fix
   the bug.

   Nix trailing whitespace.

   - Make pthread_condvar and pthread_mutex work on the stack rather than in
     pthread_t, so there's less chance of bad things happening if someone calls
     (for example) pthread_cond_broadcast() from a signal handler.

   - Remove all the deferred waiter handling except for the one case that really
     matters which is transferring waiters from condvar -> mutex on wakeup, and
     do that by splicing the condvar's waiters onto the mutex.

   - Remove the mutex waiters bit as it's another complication that's not
     strictly needed.

   Adjust previous.  In the condvar case the wakeup might already have been
   eaten.

   Nix trailing whitespace.  NFCI.

   Deal with a couple of problems with threads being awoken early due to
   timeouts or cancellation where:

   - The restarting thread calls _lwp_exit() before another thread gets around
     to waking it with _lwp_unpark(), leading to ESRCH (observed by joerg@).
     (I may have removed a similar check mistakenly over the weekend.)

   - The restarting thread considers itself gone off the sleep queue but
     at the same time another thread is part way through waking it, and hasn't
     fully completed that operation yet by setting thread->pt_mutexwait = 0.
     I think that could have potentially lead to the list of waiters getting
     messed up given the right circumstances.

   In the interests of reliability simplify waiter handling more and redo
   condvars to manage the list of waiters with atomic ops.

   - Try to eliminate a hang in "parked" I've been seeing while stress testing.
     Centralise wakeup of deferred waiters in pthread__clear_waiters() and use
     throughout libpthread.  Make fewer assumptions.  Be more conservative in
     pthread_mutex when dealing with pending waiters.

   - Remove the "hint" argument everywhere since the kernel doesn't use it any
     more.

   Sync with HEAD

   Drop most of the logic associated with pthread__started.

   The pthread_cond logic is a questionable optimisation at best and the
   post-fork logic is plainly broken.

   Merge changes from current as of 20200406

   Use pthread_condattr_t and pthread_cond_t magic fields

   Validate _PT_CONDATTR_MAGIC and _PT_COND_MAGIC respectively.

   Pull up following revision(s) (requested by ad in ticket #647):

        lib/libpthread/pthread_rwlock.c: revision 1.37 (patch)
        lib/libpthread/pthread_misc.c: revision 1.16
        lib/libpthread/pthread.c: revision 1.154
        lib/libpthread/pthread_int.h: revision 1.98
        lib/libpthread/pthread_cond.c: revision 1.66
        lib/libpthread/pthread_mutex.c: revision 1.66

   Rip out some very ambitious optimisations around pthread_mutex that are
   don't buy much.  This stuff is hard enough to get right in the kernel let
   alone userspace, and I don't trust that it's right.

   Rip out some very ambitious optimisations around pthread_mutex that are
   don't buy much.  This stuff is hard enough to get right in the kernel let
   alone userspace, and I don't trust that it's right.

   unconst the timestamp

   GSoC 2016 Charles Cui: Implement thread priority protection based on work
   by Andy Doran. Also document the get/set pshared thread calls as not
   implemented, and add a skeleton implementation that is disabled.
   XXX: document _sched_protect(2).

   Rebase to HEAD as of a few days ago.

   sync with head.

   for a reference, the tree before this commit was tagged
   as yamt-pagecache-tag8.

   this commit was splitted into small chunks to avoid
   a limitation of cvs.  ("Protocol error: too many arguments")

   Pull up the following revisions(s) (requested by prlw1 in ticket #1898):
        lib/libpthread/pthread_cond.c:  revision 1.62
        lib/libpthread/pthread_mutex.c: revision 1.57,1.59

   Partial fix for thread deadlock commonly observed with named.
   Also address PR/44756.

   Pull up the following revisions(s) (requested by prlw1 in ticket #1029):
        lib/libpthread/pthread_cond.c:  revision 1.62
        lib/libpthread/pthread_mutex.c: revision 1.57,1.59

   Partial fix for thread deadlock commonly observed with named.
   Also address PR/44756.

   remove compatibility code for handling CLOCK_MONOTONIC and handle it in the
   syscall directly.

   PR/44756: Sad Clouds: Prevent leakage of errno = ESRCH from _lwp_park. This
   has two parts:
        - in pthread_cond_timedwait() if the thread we are trying to unpark
          exited, retry the the _lwp_park call without it.
        - pthread_mutex() was affecting errno since it is calling _lwp_park()
          from pthread_mutex_lock_slow(). preserve the original errno.
   Note that the example problem still causes an occassional deadlock on machines
   with many CPUs and it is the same deadlock we observe with named.

   resync from head

   Pull up following revision(s) (requested by manu in ticket #869):
        lib/libpthread/pthread_rwlock.c: revision 1.33
        lib/libc/include/reentrant.h: revision 1.16
        lib/libpthread/pthread_cond.c: revision 1.59
        lib/libpthread/pthread_misc.c: revision 1.15
        lib/libc/thread-stub/thread-stub.c: revision 1.23
        lib/libpthread/pthread_cancelstub.c: revision 1.38
        lib/libpthread/pthread_specific.c: revision 1.26
        lib/libpthread/pthread_mutex.c: revision 1.56
        lib/libpthread/pthread_tsd.c: revision 1.11
        lib/libpthread/Makefile: revision 1.80
        lib/libpthread/pthread.c: revision 1.143
        lib/libpthread/pthread_int.h: revision 1.89
   - Allow libpthread to be dlopened again, by providing libc stubs to
   libpthread.
   - Fail if the dlopened libpthread does pthread_create(). From manu@
   - Discussed at length in the mailing lists; approved by core@
   - This was chosen as the least intrusive patch that will provide
     the necessary functionality.
   XXX: pullup to 6

   Pull up following revision(s) (requested by christos in ticket #862):
        lib/libpthread/pthread_cond.c: revision 1.60
        lib/libpthread/pthread_cond.c: revision 1.61
   PR/47703: Yasushi Oshima: pthread_cond_timedwait() does not wait
   after call pthread_condattr_setclock(CLOCK_MONOTONIC)
   _lwp_park(2) expects a realtime clock, and it gets passed a monotonic
   one.  Since monotonic < real, it never sleeps. This patch adjusts
   the monotonic clock to be a real one before it passes is to
   _lwp_park(2). This is the minimal hacky fix and it will be fixed
   properly in _lwp_park(2) in the future.
   XXX: pullup to 6.
   for safety, declare mono on the outermost block it is used.

   for safety, declare mono on the outermost block it is used.

   PR/47703: Yasushi Oshima: pthread_cond_timedwait() does not wait
   after call pthread_condattr_setclock(CLOCK_MONOTONIC)

   _lwp_park(2) expects a realtime clock, and it gets passed a monotonic
   one.  Since monotonic < real, it never sleeps. This patch adjusts
   the monotonic clock to be a real one before it passes is to
   _lwp_park(2). This is the minimal hacky fix and it will be fixed
   properly in _lwp_park(2) in the future.

   XXX: pullup to 6.

   - Allow libpthread to be dlopened again, by providing libc stubs to libpthread.
   - Fail if the dlopened libpthread does pthread_create(). From manu@
   - Discussed at length in the mailing lists; approved by core@
   - This was chosen as the least intrusive patch that will provide
     the necessary functionality.
   XXX: pullup to 6