This is the mail archive of the
mailing list for the eCos project.
"Threads on ecos" confirmation needed...
- From: Ivan Horvat <ihorvat at xylon dot hr>
- To: ecos-discuss at sources dot redhat dot com
- Date: Fri, 30 Jan 2004 19:08:50 +0100
- Subject: [ECOS] "Threads on ecos" confirmation needed...
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
may be quite useful feature in some cases/applications.
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss