This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/16410] New: pthread_cond_timedwait has 70us latency when abstime already expired
- From: "weiqi at kylinos dot com.cn" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Wed, 08 Jan 2014 01:43:31 +0000
- Subject: [Bug nptl/16410] New: pthread_cond_timedwait has 70us latency when abstime already expired
- Auto-submitted: auto-generated
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.