This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
AW: AW: AW: RFC: POSIX timers and threads in a realtime context
- From: "Warlich, Christof" <christof dot warlich at siemens dot com>
- To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>, Torvald Riegel <triegel at redhat dot com>
- Cc: Rich Felker <dalias at libc dot org>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, "Hartmann, Wolfgang" <wolfgang dot hartmann at siemens dot com>, "Sudler, Simon" <simon dot sudler at siemens dot com>
- Date: Wed, 7 Oct 2015 12:11:18 +0000
- Subject: AW: 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> <1444211613 dot 25110 dot 63 dot camel at localhost dot localdomain> <6D83E89737156549AEA25EF9ED712C5D158977 at DEFTHW99EK1MSX dot ww902 dot siemens dot net> <5615007F dot 3090706 at arm dot com>
Szabolcs Nagy wrote:
> On 07/10/15 12:01, Warlich, Christof wrote:
> > Agreed, the scenario that you describe could be implemented without
> > locking and hence, without the risk for latencies in realtime threads.
> > But imagine a more generic scenario where any thread may need to be
> > able to set up timer events sent to any other thread waiting for timer
> > events: In this case, some global associative array would still be needed.
> >
>
> communicate and store the tid the same way as you
> communicate and store the pthread_t values.
>
> (i.e. use pthread_t,tid pair instead of pthread_t
> to identify a thread throughout your code, then
> there should be no significant worst-case latency
> increase compared to the pure pthread_t usage).
Right, if one _has_ to communicate a kernel tid and if it _has_ to be done
from within the active receiving thread (because gettid() only yields the _current_
thread's kernel tid), then sending both the POSIX thread id and the related kernel
tid as a pair is a good way to go.
But as threads are typically created through pthread_create(), the POSIX thread
ids are already known right after returning from pthread_create(), which may be
before the newly created thread has even been started. Thus, there would be no
such communication path needed at all except for the sole purpose of communicating
the kernel tid.
> > Anyway, to me it also looks quite surprising to have kernel tids being
> > exposed through the GLIBC API more or less just only for timer_create()
> > with SIGEV_THREAD_ID. Allowing to provide a POSIX thread id instead
> > would make the interface much smoother IMHO.
> >
>
> pthread_t based timer_create api would make
> more sense to me than a tid based one (assuming
> there is no tid exposed in the libc otherwise).
Good, so it looks like there is quite some agreement on that so far :-) ...
>
> but exposing tid might also make sense (since it's
> user visible in /proc and through various tools)
... and I'm fully agnostic to that issue.