This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: "Threads on ecos" confirmation needed...
- From: "Slawek" <sgp at telsatgp dot com dot pl>
- To: "Ivan Horvat" <ihorvat at xylon dot hr>,<ecos-discuss at sources dot redhat dot com>
- Date: Fri, 30 Jan 2004 20:00:45 +0100
- Subject: Re: [ECOS] "Threads on ecos" confirmation needed...
- Fl-build: Fidolook 2002 (SL) 6.0.2800.85 - 28/1/2003 19:07:30
- References: <401A9DB2.1000300@xylon.hr>
Hello!
In message to <ecos-discuss@sources.redhat.com> sent Fri, 30 Jan 2004 19:08:50
+0100 you wrote:
IH> I have a question/doubt regarding threads. If I got the picture
IH> correctly, there's no way to create a thread such that the
IH> thread-object storage is automatically/dynamically allocated instead of
IH> supplied by "user" (or the thread creator). This creates the problems,
IH> as exiting thread cannot clean up its resources because:
IH> * If the thread-object storage is freed (or in c++ deconstructed) and
IH> then
IH> either cyg_thread_exit() or (directly) thread->exit() is called,
IH> the scheduler will crash soon after the "exit" call
IH> * if the thread calls "exit" routine, then it doesn't have a chance
IH> to
IH> clean up, as *exit() never returns (other thread must do the
IH> cleaning)
IH> This causes inefficiencies in pthread implementation because, for
IH> example:1) The several *detached* threads are created.
IH> 2) All the threads exit. The per-thread keys are destroyed, waiting
IH> "joiners" are "kicked" via condition variables. But, the stack
IH> spaces
IH> and spaces holding Cyg_Thread objects are still hanging around.
IH> 3) Those unreleased data hangs until the next call to
IH> pthread_create(),
IH> which first reaps all exited threads and cleans after them. There
IH> may
IH> be a lot of zombie data pending, as some threads can have big
IH> stacks,
IH> which is bad for embedded systems.
IH> Can someone please tell me whether my understanding is correct or not?
IH> And, if I got it right, would it be possible for future releases of
IH> ecos to create threads where the kernel itself would
IH> allocate/deallocate space for thread object? Probably, this may have
IH> negative impact on RT performance, but
IH> may be quite useful feature in some cases/applications.
Im my opinion there is no need to alter eCos behaviour. eCos does *not* need
malloc/free so kernel should not use it. Threads' data can be allocated in
global storage and/or on stacks and *nobody* should free that.
Obviously you can implement auto-free feature if you want. There is even no
need to modify existing eCos code!
One simple example (my first though):
1) create a special "free threads' storage" thread, give it the lowest
possible priority (one higher the idle thread)
2) make this thread wait on mailbox, read from mailbox data mean memory
addresses which are supposed to be freed, so free everything you receive.
3) make each dynamically allocated thread to put it's stack and/or thread
data to this mailbox and issue thread->exit right after that.
You may need to modify it a little bit if you're using SMP system or if you
cannot guarantee that the exiting thread would *not* hold for a while after
putting data into mailbox but before final exit (normally threads'
priorities should take care about it).
--
Slawomir Piotrowski
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss