This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/18463] pthread_cond_broadcast issue when surrounded by PTHREAD_PRIO_INHERIT mutex on ARM
- From: "adhemerval.zanella at linaro dot org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Mon, 16 May 2016 07:48:24 +0000
- Subject: [Bug nptl/18463] pthread_cond_broadcast issue when surrounded by PTHREAD_PRIO_INHERIT mutex on ARM
- Auto-submitted: auto-generated
- References: <bug-18463-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=18463
--- Comment #13 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
For __ASSUME_FUTEX_LOCK_PI, which will use FUTEX_{LOCK,UNLOCK}_PI, glibc can
assume it will return -ENOSYS in all the cases since 'do_futex' will first
check if 'futex_cmpxchg_enabled' is defined by the architecture. And as far I
could check, the missing one that does not really support
futex_atomic_cmpxchg_inatomic in 3.2 (arm, m68k, mips, sparc) will either
return if it supports or use the default futex.h implementation that returns
-ENOSYS.
But we can not assume the same thing for __ASSUME_REQUEUE_PI which will use the
FUTEX_WAIT_REQUEUE_PI and FUTEX_CMP_REQUEUE_PI operation, since for linux v3.2
there is no runtime check in kernel/futex.c. This is only done by
59263b513c11398cd66a52d4c5b2b118ce1e0359 which only appears on v3.4.
The possible cleanup I see is to remove __ASSUME_FUTEX_LOCK_PI, since kernel
will return -ENOSYS for all supported arch if futex_atomic_cmpxchg_inatomic is
not supported in the particular kernel configuration; and change the
__ASSUME_REQUEUE_PI minimum kernel for arm to enable it for v3.4+.
--
You are receiving this mail because:
You are on the CC list for the bug.