This is the mail archive of the libc-alpha@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]

AW: AW: RFC: POSIX timers and threads in a realtime context


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


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