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

[Ivan Horvat <ihorvat at xylon dot hr>]

Hi.

> 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!
>  

I didn't mean to use malloc/free. If I recall well, there is a hard 
limit on number of
threads that can be created in ecos (correct me if I'm wrong). So, one 
can declare an
array of Cyg_Thread objects (firts thought, also:-):

     Cyg_Thread thr_slots[MAX_THREADS];

with number of elements that is equal to maximum number of threads. 
Then, changes
are quite simple. For example, cyg_thread_create() could be modified 
first to find a
free "slot". Then, instead of placing the object into user supplied 
space pointed by
'thread':

     Cyg_Thread *t = new((void *)thread) Cyg_Thread (...);

it should place it in one of the "empty slots":

     Cyg_Thread *t = new((void *)&thr_slots[empty]) Cyg_Thread (...);

Then, Cyg_Thread::exit() should be also modified to find the 'self' 
within the 'thr_slots'
and mark it as unallocated, available for future use. This would enable 
elegant and
automatic termination of "detached" threads (which I need in large 
quantities :-).

The stack could be freed/cleaned by the exiting thread before calling 
*exit() (I think) and
the above solution would "free" the space for thread object.

Of course, this is just a preliminary idea...


> 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).
>
>
>  

Yes, this is a solution, but it requires another "garbage collector" 
thread. I would like
to have the similar functionality provided by e.g Linux or Solaris; one 
can create a
detached thread, and don't have to worry about its completion, as kernel 
resources are
automatically cleaned-up.



Thanks for help,
Ivan.




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