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

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

Torvald Riegel wrote:
> On Tue, 2015-10-06 at 07:59 +0000, Warlich, Christof wrote:
> > 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.
> 
> I don't think it's a problem to let the target thread (ie, the one that
> is supposed to get the timer events) to communicate its tid.  First,
> thread startup is slow anyway, so even some additional handshake doesn't
> really matter I believe; I suppose your also not creating large numbers
> of threads, given that you're in a realtime setting.
> The master thread (ie, the one creating the target thread) can just
> supply an address where the target thread's tid is to be stored.  So
> this doesn't really need locking because the target thread can just
> write the tid there, and with atomic operations.
> The master thread could wait until the target thread has written the
> tid, or it could even just not send events until it has.  The check by
> the master is just a simple memory_order_relaxed atomic load, given that
> there's no invariant to other stuff in this case.  This may make it
> possible that the target thread is running but the written tid hasn't
> reached the master thread through the cache hierarchy, but that seems
> not a problem for a timer use case.

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.

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.