This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: AW: AW: RFC: POSIX timers and threads in a realtime context
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: "Warlich, Christof" <christof dot warlich at siemens 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, 07 Oct 2015 12:22:39 +0100
- Subject: Re: 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>
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).
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).
but exposing tid might also make sense (since it's
user visible in /proc and through various tools)