| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
Errors from _thr_umutex_unlock2 should "never happen" in normal
circumstances. If they do, however, return them to the application
so it can fail early and loudly. Hiding the errors will only delay
the inevitable failure, making it harder to find and diagnose.
Submitted by: Eric van Gyzen <eric_van_gyzen@dell.com>
Obtained from: Dell Inc.
PR: 198914
MFC after: 1 week
|
|
|
|
|
| |
Further decreases unexpected context switches by defering mutex wakeup
until internal sleep queue lock is released.
|
|
|
|
|
|
|
| |
be acquired.
PR: 168317
MFC after: 3 days
|
|
|
|
| |
Found by: clang static analyzer
|
|
|
|
| |
significant for lock owner.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Add flags CVWAIT_ABSTIME and CVWAIT_CLOCKID for umtx kernel based
condition variable, this should eliminate an extra system call to get
current time.
- Add sub-function UMTX_OP_NWAKE_PRIVATE to wake up N channels in single
system call. Create userland sleep queue for condition variable, in most
cases, thread will wait in the queue, the pthread_cond_signal will defer
thread wakeup until the mutex is unlocked, it tries to avoid an extra
system call and a extra context switch in time window of pthread_cond_signal
and pthread_mutex_unlock.
The changes are part of process-shared mutex project.
|
|
|
|
|
| |
it can not fix race condition in application code, as a result,
the problem described in PR threads/151767 is avoided.
|
| |
|
|
|
|
|
|
|
|
| |
same null value, the code can not distinguish between them, to
fix the problem, now a destroyed object is assigned to a non-null
value, and it will be rejected by some pthread functions.
PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP is changed to number 1, so that
adaptive mutex can be statically initialized correctly.
|
|
|
|
|
|
|
|
| |
module private type, when private type mutex is locked/unlocked, thread
critical region is entered or leaved. These changes makes fork()
async-signal safe which required by POSIX. Note that user's atfork handler
still needs to be async-signal safe, but it is not problem of libthr, it
is user's responsiblity.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
locked and unlocked completely in userland. by locking and unlocking mutex
in userland, it reduces the total time a mutex is locked by a thread,
in some application code, a mutex only protects a small piece of code, the
code's execution time is less than a simple system call, if a lock contention
happens, however in current implemenation, the lock holder has to extend its
locking time and enter kernel to unlock it, the change avoids this disadvantage,
it first sets mutex to free state and then enters kernel and wake one waiter
up. This improves performance dramatically in some sysbench mutex tests.
Tested by: kris
Sounds great: jeff
|
|
|
|
|
| |
- Remove unused flags MUTEX_FLAGS_* and their code.
- Check validity of the timeout parameter in mutex_self_lock().
|
|
|
|
|
|
|
|
| |
testing it turns out 200 was too short to give good adaptive
performance.
Reviewed by: jeff
MFC after: 1 week
|
|
|
|
| |
Reviewed by: davidxu
|
|
|
|
|
|
| |
will work in simple cases, but may fail in more complicated ones.
Reviewed by: davidxu
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
the semantics of pthread_mutex_islocked_np() to return true if and only if
the mutex is held by the current thread.
Obviously, change the regression test to match.
MFC after: 2 weeks
|
|
|
|
|
|
|
| |
locked. This is intended primarily to support the userland equivalent
of the various *_ASSERT_LOCKED() macros we have in the kernel.
MFC after: 2 weeks
|
| |
|
|
|
|
|
|
|
|
| |
loop count.
2. Add function pthread_mutex_setyieldloops_np to turn a mutex's yield
loop count.
3. Make environment variables PTHREAD_SPINLOOPS and PTHREAD_YIELDLOOPS
to be only used for turnning PTHREAD_MUTEX_ADAPTIVE_NP mutex.
|
|
|
|
|
|
| |
add missing brackets.
MFC: after 1 day
|
|
|
|
| |
were obscured by pseudo-opaque pthreads API pointer casting.
|
|
|
|
|
| |
(part of libc) can use pthreads mutexes without causing infinite recursion
during initialization.
|
|
|
|
| |
warnings.
|
|
|
|
| |
implementation always does lock in kernel.
|
| |
|
| |
|
|
|
|
|
|
| |
default (errorcheck) mutexes do.
Noticed by: davidxu
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to tune pthread mutex performance:
1. LIBPTHREAD_SPINLOOPS
If a pthread mutex is being locked by another thread, this environment
variable sets total number of spin loops before the current thread
sleeps in kernel, this saves a syscall overhead if the mutex will be
unlocked very soon (well written application code).
2. LIBPTHREAD_YIELDLOOPS
If a pthread mutex is being locked by other threads, this environment
variable sets total number of sched_yield() loops before the currrent
thread sleeps in kernel. if a pthread mutex is locked, the current thread
gives up cpu, but will not sleep in kernel, this means, current thread
does not set contention bit in mutex, but let lock owner to run again
if the owner is on kernel's run queue, and when lock owner unlocks the
mutex, it does not need to enter kernel and do lots of work to resume
mutex waiters, in some cases, this saves lots of syscall overheads for
mutex owner.
In my practice, sometimes LIBPTHREAD_YIELDLOOPS can massively improve performance
than LIBPTHREAD_SPINLOOPS, this depends on application. These two environments
are global to all pthread mutex, there is no interface to set them for each
pthread mutex, the default values are zero, this means spinning is turned off
by default.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is also implemented in glibc and is used by a number of existing
applications (mysql, firefox, etc).
This mutex type is a default mutex with the additional property that
it spins briefly when attempting to acquire a contested lock, doing
trylock operations in userland before entering the kernel to block if
eventually unsuccessful.
The expectation is that applications requesting this mutex type know
that the mutex is likely to be only held for very brief periods, so it
is faster to spin in userland and probably succeed in acquiring the
mutex, than to enter the kernel and sleep, only to be woken up almost
immediately. This can help significantly in certain cases when
pthread mutexes are heavily contended and held for brief durations
(such as mysql).
Spin up to 200 times before entering the kernel, which represents only
a few us on modern CPUs. No performance degradation was observed with
this value and it is sufficient to avoid a large performance drop in
mysql performance in the heavily contended pthread mutex case.
The libkse implementation is a NOP.
Reviewed by: jeff
MFC after: 3 days
|
| |
|
| |
|
| |
|
|
|
|
| |
mutex in right order sorted by priority ceiling.
|
|
|
|
| |
it as a default spin cycle count.
|
|
|
|
|
| |
operation, if it is failed, we call syscall directly, this saves
one atomic operation per lock contention.
|
| |
|
| |
|
|
|
|
|
|
| |
into pthread structure to keep track of locked PTHREAD_PRIO_PROTECT mutex,
no real mutex code is changed, the mutex locking and unlocking code should
has same performance as before.
|
| |
|
|
|
|
| |
Ok'ed by: davidxu
|
| |
|
|
|
|
|
| |
Completly drop recursive mutex in pthread_cond_wait and restore recursive
after resumption. Reorganize code to make gcc to generate better code.
|
| |
|
|
|
|
|
|
|
|
|
| |
to make it work, turnstile like mechanism to support priority
propagating and other realtime scheduling options in kernel
should be available to userland mutex, for the moment, I just
want to make libthr be simple and efficient thread library.
Discussed with: deischen, julian
|
| |
|
| |
|
|
|
|
| |
while here, add some comments about process shared mutex.
|
| |
|