• R
    make futex operations use private-futex mode when possible · bc09d58c
    Rich Felker 提交于
    private-futex uses the virtual address of the futex int directly as
    the hash key rather than requiring the kernel to resolve the address
    to an underlying backing for the mapping in which it lies. for certain
    usage patterns it improves performance significantly.
    
    in many places, the code using futex __wake and __wait operations was
    already passing a correct fixed zero or nonzero flag for the priv
    argument, so no change was needed at the site of the call, only in the
    __wake and __wait functions themselves. in other places, especially
    where the process-shared attribute for a synchronization object was
    not previously tracked, additional new code is needed. for mutexes,
    the only place to store the flag is in the type field, so additional
    bit masking logic is needed for accessing the type.
    
    for non-process-shared condition variable broadcasts, the futex
    requeue operation is unable to requeue from a private futex to a
    process-shared one in the mutex structure, so requeue is simply
    disabled in this case by waking all waiters.
    
    for robust mutexes, the kernel always performs a non-private wake when
    the owner dies. in order not to introduce a behavioral regression in
    non-process-shared robust mutexes (when the owning thread dies), they
    are simply forced to be treated as process-shared for now, giving
    correct behavior at the expense of performance. this can be fixed by
    adding explicit code to pthread_exit to do the right thing for
    non-shared robust mutexes in userspace rather than relying on the
    kernel to do it, and will be fixed in this way later.
    
    since not all supported kernels have private futex support, the new
    code detects EINVAL from the futex syscall and falls back to making
    the call without the private flag. no attempt to cache the result is
    made; caching it and using the cached value efficiently is somewhat
    difficult, and not worth the complexity when the benefits would be
    seen only on ancient kernels which have numerous other limitations and
    bugs anyway.
    bc09d58c
pthread_mutex_lock.c 210 字节