Re: Kernel KAPI and instrumentation mods

[Nick Garnett <nickg at ecoscentric dot com>]

Jonathan Larmour <jifl@eCosCentric.com> writes:

> Hi Nick,
> 
> I was looking over the patch while going through the backlog and was
> wondering about the following function. While the scheduler is locked
> inside the function, it obviously may well not be outside. In that
> case the thread being pointed to by current may have exitted and the
> memory (at least partially) reused since the last invocation of
> cyg_thread_get_next(). For example the unique id in the thread
> structure could be intact, but the list pointers scribbled on.

Well, I also added an assignment in the thread destructor to zero the
thread id. So if the memory has been reused, even for another thread,
the id check will fail and it won't touch the list links.

> > +cyg_bool_t cyg_thread_get_info( cyg_handle_t threadh,
> > +                                cyg_uint16 id,
> > +                                cyg_thread_info *info )
> > +{
> > +    cyg_bool_t result = true;
> > +    Cyg_Thread *thread = (Cyg_Thread *)threadh;
> > +    +    Cyg_Scheduler::lock();
> > +    +    if( thread->get_unique_id() == id && info != NULL )
> > +    {
> 
> Why pass in the id at all if it must match the thread handle?

For the same reason as above. The thread object memory may have been
reused in the interim. Double checking the id give us a simple
integrity check. 

-- 
Nick Garnett - eCos Kernel Architect
http://www.eCosCentric.com/