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: "Threads on ecos" confirmation needed...


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


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