[ECOS] "Threads on ecos" confirmation needed...

Ivan Horvat ihorvat@xylon.hr
Fri Jan 30 18:11:00 GMT 2004


I have a question/doubt regarding threads. If I got the picture correctly,
there's no way to create a thread such that the thread-object storage is
automatically/dynamically allocated instead of supplied by "user" (or the
thread creator). This creates the problems, as exiting thread cannot clean
up its resources because:
  * If the thread-object storage is freed (or in c++ deconstructed) and then
    either cyg_thread_exit() or (directly) thread->exit() is called,
    the scheduler will crash soon after the "exit" call
  * if the thread calls "exit" routine, then it doesn't have a chance to
    clean up, as *exit() never returns (other thread must do the cleaning)

This causes inefficiencies in pthread implementation because, for example:
  1) The several *detached* threads are created.
  2) All the threads exit. The per-thread keys are destroyed, waiting
     "joiners" are "kicked" via condition variables. But, the stack spaces
     and spaces holding Cyg_Thread objects are still hanging around.
  3) Those unreleased data hangs until the next call to pthread_create(),
     which first reaps all exited threads and cleans after them. There may
     be a lot of zombie data pending, as some threads can have big stacks,
     which is bad for embedded systems.

Can someone please tell me whether my understanding is correct or not?

And, if I got it right, would it be possible for future releases of ecos to
create threads where the kernel itself would allocate/deallocate space for
thread object? Probably, this may have negative impact on RT 
performance, but
may be quite useful feature in some cases/applications.


Ivan Horvat.

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

More information about the Ecos-discuss mailing list