Adding support for Real Time
"Perez-Gonzalez, Inaky" <[email protected]>
| Newsgroups | gmane.linux.ngpt.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi All
I am working on adding the necessary support for real time threading to
NGTP, basing my work on 1.2.2. I am hitting some problems that I don't know
how would it be more proper to address and I would like to ask for your
advice:
1) How do I destroy a native thread? When setting the scheduler for
SCHED_FIFO or SCHED_RR, I do a 1:1, binding the thread to a native thread
that is set to be FIFO/RR with the thread's priority. However, when changing
it/destroying the thread, I have to delete the native thread [I could also
recycle it, simply resetting the scheduling policy to SCHED_OTHER].
2) I need an operation for unbinding threads from native threads; I
implemented it like this:
/* Do the unbinding ugly work */
void __pth_unbindfromnative(pth_t t)
{
pth_descr_t descr = t->boundnative;
t->boundnative = NULL;
descr->is_bounded = FALSE;
descr->bounded_thread = NULL;
descr->current = NULL;
pth_max_native_threads--;
}
/* unbind the given thread */
int pth_unbindfromnative(pth_t t)
{
pth_descr_t descr = pth_get_native_descr();
/* verify it is bounded */
if (t->boundnative == NULL)
return TRUE;
/* Can't bind a null thread... */
if (t == NULL || native_is_group_leader)
return FALSE;
/* FIXME: remove? should not have any element in wait_queue.... */
if (pth_pqueue_elements(&(t->boundnative->wait_queue)))
return FALSE;
#warning FIXME: lock?
__pth_unbindfromnative (t);
return TRUE;
}
I am not sure at all on the pth_pqueue_elements() check -I copied it
blindly, call it faith- Would any kind should give a quick and fast
explanation on why shouldn't bind state be changed when there are elemenrs
in the wait queue? [well, I think I know the answer, but want to be really
sure] What I also need is some hints on how to fix it.
I am coordinating this work with Dave Howell, but I did not want to bug him
too much ...
Thanks in advance!
Iñaky Pérez González::[email protected]
I do not speak for Intel Corp, opinions are my own.