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/16410] New: pthread_cond_timedwait has 70us latency when abstime already expired


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

            Bug ID: 16410
           Summary: pthread_cond_timedwait has 70us latency when abstime
                    already expired
           Product: glibc
           Version: 2.18
            Status: NEW
          Severity: normal
          Priority: P2
         Component: nptl
          Assignee: unassigned at sourceware dot org
          Reporter: weiqi at kylinos dot com.cn
                CC: drepper.fsp at gmail dot com

Created attachment 7340
  --> https://sourceware.org/bugzilla/attachment.cgi?id=7340&action=edit
the test.c for this problem

Since this patch
(http://repo.or.cz/w/glibc.git/commit/e88726b483a275824e852f64476087568dbae7bb),
it seems that  pthread_cond_timedwait.S does not care the arg "abstime" which
may already expired. Pass it to syscall futex, if the futex have the ability
FUTEX_CLOCK_REALTIME. 

    Before the futex_clock_realtime patch, pthread_cond_timedwait.S check the
abstime arg firstly by syscall clock_gettime, so if abstime already expired,
pthread_cond_timedwait would return -ETIMEDOUT immediatly.

    I have reported a bug to redhat bugzilla described this
case(https://bugzilla.redhat.com/show_bug.cgi?id=1048731),and added a test.c
show this.

    The kernel futex_wait use hrtimer to calculate timeout, and do not special
considerations such cases.

-- 
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]