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]

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


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.


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