This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug nptl/25118] New: Excess futex syscall while using pthread_cond_wait()


https://sourceware.org/bugzilla/show_bug.cgi?id=25118

            Bug ID: 25118
           Summary: Excess futex syscall while using pthread_cond_wait()
           Product: glibc
           Version: 2.30
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: nptl
          Assignee: unassigned at sourceware dot org
          Reporter: ioctl at ya dot ru
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

Created attachment 12045
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12045&action=edit
pthread_cond_wait() test

I have the simple test program (please, see attachment).

I run it, then run strace -tt -p _main_process_pid_ and get output like this:

11:44:59.790924 restart_syscall(<... resuming interrupted nanosleep ...>) = 0
11:45:00.104353 futex(0x5645bdddb0ec, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
11:45:01.104260 futex(0x5645bdddb080, FUTEX_WAKE_PRIVATE, 1) = 0
11:45:01.104533 write(2, "w", 1)        = 1
11:45:01.104889 nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffe40eae640) = 0
11:45:02.105349 futex(0x5645bdddb0e8, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
11:45:03.104367 futex(0x5645bdddb080, FUTEX_WAKE_PRIVATE, 1) = 0
11:45:03.104563 write(2, "w", 1)        = 1
11:45:03.104876 nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffe40eae640) = 0
11:45:04.105407 futex(0x5645bdddb0ec, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
11:45:05.104502 futex(0x5645bdddb080, FUTEX_WAKE_PRIVATE, 1) = 0
11:45:05.104684 write(2, "w", 1)        = 1
...

There are futex wake calls that wakes no one process. These syscalls are
performed by the pthread_mutex_unlock() calls.

It's because glibc __pthread_cond_wait_common() calls
__pthread_mutex_cond_lock(), that sets mutex->__data.__lock to value 2.
There are a lot of comments inside the code, and I sure there was a reason to
do so, but I cannot understand it.

In cases like a program attached these functions seems doesn't work optimal.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]