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

["Warlich, Christof" <christof dot warlich at siemens dot com>]

Rich Felker wrote:
> On Mon, Oct 05, 2015 at 03:04:31PM +0000, Warlich, Christof wrote:
> > Unfortunately, there is no interface to send timer events to
> > _another_ dedicated POSIX thread of the current process, because
> > there is no interface that calculates the kernel thread id for
> > another than the current POSIX thread id.
> 
> There is if the target thread gets and reports its own kernel tid,
> which seems practical to do since you would presumably only want to
> send such timer event signals to a thread which is already prepared to
> handle them... 

Yes, certainly any POSIX thread that is supposed to receive timer events may obtain its kernel tid, e.g. right at its start. Then, to make these kernel tids ubiquitously available to other
threads that may want to set up appropriate timers, it would require to store those kernel tids in some sort of global associative array, with the POSIX thread id being the array's index.

But while this 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.

Either of the two suggested interface extensions would these latencies. They both even avoid the need for an additional system call (i.e. gettid()), as the kernel thread tid lookup may just be implemented by a C struct member lookup. 
 
> Or are you intending to use this for some sort of
> instrumentation/profiling purpose where you would be targeting threads
> that don't expect a signal?

No, I'm not.

> > To get around this restriction, I'd like to suggest extending the
> > GLIBC API to support sending timer events to arbitrary POSIX threads
> > belonging to the current process by either:
> > 
> > introducing a new Linux specific function that calculates the kernel
> > thread id from a POSIX thread id along the lines
> >         pid_t pthread_to_tid_np (pthread_t id) {
> >                 return ((struct pthread *) id)->tid;
> >         }
> > 
> > or:
> > 
> > introducing a new Linux-specific sigev_notify value named e.g.
> > SIGEV_PTHREAD_ID and a new member in struct sigevent, e.g.
> > _sigev_un._pthread, allowing to directly pass a POSIX thread id to
> > struct sigevent. Furthermore, adding something like #define
> > sigev_notify_pthread _sigev_un._sigev_thread._pthread to siginfo.h
> > would then be appropriate to make access to the newly defined
> > interface look nicer.
> > ....
> > Personally, I'd be in favor for the second of the presented
> > solutions, as it would not expose kernel thread ids to application
> > code and would more smoothly fit into the currently available
> > interface.
>
> AFAIK there is still an unresolved question as to whether glibc wants
> to expose kernel tids as an API. This is the reason there is no
> gettid() function and you have to use syscall(). Other interfaces are
> affected too.

This is in line with me to favor the second of the two solution presented above (i.e. introducing SIGEV_PTHREAD_ID), as it would not _require_ to expose kernel tids as an API.
 
> Note that even if glibc does want to support your proposed usage,
> there are two possible approaches. One is exposing the kernel tid. The
> other is having timer_create accept userspace pthread_t identifiers
> and translating them internally.

Just to emphasize this again: I'm asking for this interface extension to allow better realtime support. I'm not sure how much this matters to the GLIBC community, but from my point of view, it would be a shame if this would not be considered, taking into account the effort spent on the Linux kernel side for better realtime support with both RT_PREEMPT and Xenomai.

> These are incompatible approaches so some consideration of
> their pros and cons is needed before adopting one or the other.

Well, technically, both solutions _could_ be implemented simultaneously, but as this would not make much sense, I totally agree that we need to consider the pros and cons of either suggestion.

The first suggestion is just the trivial addition of the trivial Linux specific function

thread id from a POSIX thread id along the lines
        pid_t pthread_to_tid_np (pthread_t id) {
                return ((struct pthread *) id)->tid;
        }

to the GLIBC, so it just captivates by its simplicity, but has the disadvantage that it exposes the kernel tid to user space without any logical reason.

The second solution, adding a new sigev_notify id (e.g. SIGEV_PTHREAD_ID), is only slightly more complex and, similar to the first suggestion, has no side effects w.r.t. backward compatibility. Thus, I cannot see any disadvantages here.

Please advise how to proceed: Does it make sense if I send a patch?

Chris