This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos 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: Thread destructors


Hi Ivan,

Thanks for the fast response. I hope you've had a happy 
easter.

>> I have read somewhere the suggestion of using message 
boxes. 
>> Does this mean that I can can put a message in a message 
box 
>> with for example the stack address and then let another 
>> thread do the clean up? Will this work as long as the 
clean-
>> up thread has a lower priority than the thread exiting?
>
>This would work, under exactly these conditions you already 
mentioned:
>1) the cleaning is done from *another* context (i.e. thread)
>2) the other thread that performs cleaning *must* have lower 
priority 
>than any other thread it is supposed to clean
>
>Yet, this is incomplete... The thread whose resources are to 
be 
>deallocated must first perform cyg_thread_exit()
>(of course, otherwise the lower priority thread wouldn't get 
chance to 
>run at all). But, remember the
>cyg_thread_create() function and its last parameter? It is a 
pointer to 
>"cyg_thread" object, that is handled as a
>"black-box" structure. However, this structure is also often 
allocated 
>by malloc(), and *cannot* just be freed in the
>cleaner (or usually called reaper) thread, as the scheduler 
depends on 
>the link pointers in that structure in order to
>operate properly. If this space is just freed, then other 
thread may 
>obtain it and corrupt the pointers causing the
>scheduler to crash. Thus, to fully clean the thread, you 
must first call 
>cyg_thread_delete() with the "cyg_handle_t"
>parameter associated to the "cyg_thread" object in question, 
which would 
>remove that "cyg_thread" object from
>the scheduler's list. Only now, it is "safe" to free the 
space occupied 
>by the "cyg_thread" object.
>
> From my experience: if you don't perform the 
cyg_thread_delete() then 
>the "cyg_thread" object can be "reused", but
>only for the purposes of creating the new thread (i.e. 
passing it to the 
>cyg_thread_create() as its last argument).
>Any other use (usually) leads to imminent scheduler crash...
>

I didn't grasp this at first, but I guess that what you are 
saying is that even though I have exited the thread for which 
I would like to free up memory I can't just do that in the 
reaper thread as it still "being used" by the scheduler. So 
in the reaper thread I have to call cyg_thread_delete before 
doing any clean-up (ie stack, thread object and handle)? Does 
this also mean that if I wanted I could restart the thread by 
calling the cyg_thread_resume? 
  
void ReaperThread(cyg_addrword_t pParam) 
{

  // pParam is a pointer to our message box
  cyg_handle_t hMsgBox = *((cyg_handle_t *)pParam);

  while(1) {
    // Wait for an exiting thread to send us a message
    // The message contains the address to its data
    ThreadData *ptp = cyg_mbox_get(hMsgBox);
    // "Disconnect" thread for the scheduler
    cyg_thread_delete(ptp->hThread);
    // Delete the threads allocated stack
    delete [] ptp->pStack;
    // Delete rest of its data (handle,object, etc..)
    delete ptp;
  }

}

Regards,

Chris

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


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