This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
AW: AW: RFC: POSIX timers and threads in a realtime context
- From: "Warlich, Christof" <christof dot warlich at siemens dot com>
- To: Joseph Myers <joseph at codesourcery dot com>, Rich Felker <dalias at libc dot org>, Zack Weinberg <zackw at panix dot com>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, "Sudler, Simon" <simon dot sudler at siemens dot com>, "Hartmann, Wolfgang" <wolfgang dot hartmann at siemens dot com>
- Date: Wed, 7 Oct 2015 05:56:20 +0000
- Subject: AW: AW: RFC: POSIX timers and threads in a realtime context
- Authentication-results: sourceware.org; auth=none
- References: <6D83E89737156549AEA25EF9ED712C5D158489 at DEFTHW99EK1MSX dot ww902 dot siemens dot net> <20151005160303 dot GK8645 at brightrain dot aerifal dot cx> <6D83E89737156549AEA25EF9ED712C5D1585ED at DEFTHW99EK1MSX dot ww902 dot siemens dot net> <alpine dot DEB dot 2 dot 10 dot 1510061203190 dot 4225 at digraph dot polyomino dot org dot uk>
Joseph Myers wrote:
> I think a separate thread should be started seeking to establish a
> consensus on whether gettid and pthread_gettid_np (see bug 6399) should be
> added to glibc as part of the OS-independent GNU API.
Thanks for the pointer to bug 6399, which to me gives a rather comprehensive picture on the various alternatives and their implications. I don't really understand the benefit to start over with a new thread tough: This would bear the risk of losing the context that I'm interested in, because wrapping gettid() (being the initial request in bug 6399) doesn't help at all to address the (realtime) scenario according of the points summarized in my previous post:
But while the gettid() approach works rather well for ordinary
applications, it doesn't scale into the realtime domain, which
I'm focused at: Access to the associative array would most
likely need some sort of locking, and the kernel tid would only
be available after the related thread has finished its startup
code, so again some synchronization mechanism must be put
into place. For realtime applications, this may easily introduce
unacceptable latencies.
Thus, the options remain the same as initially suggested (with the names slightly adapted to match those used in bug 6399):
1) Add a pthread_gettid_np(pthread_t *thr) function
2) Add SIGEV_PTHREAD_ID
> That will require
> careful analysis of the concept of tids in different operating systems,
> not just Linux, to understand how OS-independent such a concept is
Huh, I wonder if someone new to GLIBC development like me would be able to do that in any sensible amount of time. Which operating systems besides Linux are to be considered? And anyway, shouldn't this step have been done before introducing the already existing GLIBC interfaces that do already require kernel tids?
> as well as of Linux interfaces taking tids, and of glibc interfaces
> taking them (whether correctly or incorrectly).
In fact, as I already pointed out, I'm not really happy with exposing kernel tids to user space, as I do not see a logical reason to do so.
For an overview of interfaces using tids or pids, I shamelessly copied the list from bug 6399:
System call only:
gettid()
get_robust_list()
set_robust_list()
perf_event_open()
ioprio_set()
ioprio_get()
tgkill()
GLIBC:
clone()
fcntl() F_SETOWN, F_GETOWN, G_GETOWN_EX, F_SETOWN_EX
timer_create() SIGEV_THREAD_ID
sched_getaffinity()
sched_setaffinity()
sched_getparam()
sched_setparam()
sched_getscheduler()
sched_setscheduler()
For some (most!) of the GLIBC functions listed above, there are already aquivalent GLIBC funntions that use POSIX thread ids instead of tids:
pthread_getaffinity_np() pthread_attr_getaffinity_np()
pthread_setaffinity_np() pthread_attr_setaffinity_np()
pthread_getschedparam() pthread_attr_getschedparam()
pthread_setschedparam() pthread_attr_setschedparam()
pthread_attr_getschedpolicy()
pthread_attr_setschedpolicy()l
Thus, focusing on the GLIBC interfaces and ignoring clone() as we talk about POSIX threads here, which should not be created through clone() but are created in a safe way through pthread_create(), the only functions that remain to be considered to be amended by POSIX thread interfaces might be
fcntl() F_SETOWN, F_GETOWN, G_GETOWN_EX, F_SETOWN_EX
timer_create() SIGEV_THREAD_ID
But fcntl() F_SETOWN, F_GETOWN, G_GETOWN_EX, F_SETOWN_EX seems to be targeting processes, not threads, right? Thus, it looks like only timer_create() needs to be "fixed" by
adding SIGEV_PTHREAD_ID to give it a POSIX thread interface.
> It will also require active work
> understanding the different points of view expressed in that thread and
> seeking to find common ground; consensus is unlikely to arise simply
> through starting discussion and then watching it.
I'll do my best, but I'll certainly need the GLIBC community's support.
> If a consensus supporting the addition of such APIs is established, a
> patch implementing them can be submitted (make sure to complete the
> copyright assignment paperwork before sending the patch).
Ok, though it seems quite a way to go to come to that point.
> If consensus is against them in the OS-independent API,
> we may wish to look at the libinux-syscalls concept for them.
>From the follow-up discussion between Joseph, Rich and Zack, I take that a Linux-only approach to expose the kernel tid by inspecting struct pthread would not be acceptable and that amending timer_create() with SIGEV_PTHREAD_ID would have far better chances to be accepted. If starting a new thread on the topic is the way to proceed, I'd like to start that thread by only considering that remaining option, i.e. amending timer_create() with SIGEV_PTHREAD_ID. Could we agree on this?
Thanks,
Chris