Thread management (killing threads)

[Rob van Lieshout (PragmaLab)]

Hi all,

our application (internetradio on a Mega256 using NutOs 4.3.3) has reached
the point that new threads have to be added but RAM (heap) becomes a real
bottleneck. The good news is that by design, not all threads don't have to
run concurrent: eg we play from a card, or from the internet, never at the
same time. And there are more tasks (threads) that never will have to run
concurrent. But like most (all?) NUtOS users, we create all threads at
startup, thus claiming the stack needed for that thread, while only using it
when the trhead is not in the idle state.

To use resources in a more efficient way, the smartest thing to do seems to
manage threads in a more dynamic way: in stead of creating them at startup,
we create them at the moment we need them. And when the task is finished,
kill the thread so the resources, especially the stackspace, becomes
available again.

I know that in the history of NutOS killing threads has always been
troublesome and I searched the archives to see what the current status was
on this topic, without any new clues. Simply calling 'NutThreadKill' from
the running thread doesn't work, at least that is my experience so far.

So:

- is anyone there using threadmanagement in a more dynamic way?
- is anyone using 'NutThreadKill()' with more succes?

Thanks for you time and answers....

Regards,

Rob van Lieshout

 

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Moritz 'Morty' Struebe]

Hi Rob,

the main problem with killing threads is the memory management. You need
to know which memory was allocated to which thread, so you can free it
when you kill a thread. About a year ago I've written some code to do
this and also sent some patches which partly made it into the Nut/OS
codebase. If you are interested I can search that code. Shouldn't be too
much trouble to add it to the current codebase, as HEAPNODE ist now used
everywhere.
Basically you have to add an thread-element and a next-element to
HEAPNODE. When allocating you write current-thread to the memory and
link it into the list (as with the debug-code). When killing a thread
you need to walk the list and free all memory which isn't needed any more.

I can also send you my Diploma Theses, which also describes this
problem. It's in German, though.

Morty




Am 07.07.2009 10:39, schrieb PragmaLab:

> Hi all,
>
>
> So:
>
> - is anyone there using threadmanagement in a more dynamic way?
> - is anyone using 'NutThreadKill()' with more succes?
>
> Thanks for you time and answers....
>
> Regards,
>
> Rob van Lieshout
>
>  
>
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>  

--
Dipl.-Ing. Moritz 'Morty' Struebe (Wissenschaftlicher Mitarbeiter)
Lehrstuhl für Informatik 4 (Verteilte Systeme und Betriebssysteme)
Friedrich-Alexander-Universität Erlangen-Nürnberg
Martensstr. 1
91058 Erlangen

WWW          : http://www4.informatik.uni-erlangen.de/~morty
eMail        : struebe@...




_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Michael Jones-11]

Rob van Lieshout wrote:

>The good news is that by design, not all threads don't have to
>run concurrent: eg we play from a card, or from the internet, never at the
>same time.

Why bother with multiple threads then? One thread used as an dispatcher will
be the easiest way to do this.


Cu,
Michael

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Nathan Moore-5]

Memory management isn't the only problem if you are trying to kill threads
from other threads.All allocated resources are issues and each needs their
own special handling.  NutOS has no
idea which files to call _close on or which semaphores, mutexes, or whatever
to exit on behalf
of the thread.  It does have know about which events a thread may be waiting
on, though, but if
an event is part of a mutex or semaphore it doesn't know that the thread
needs to post that event
or do any other book keeping for the mutex or semaphore on behalf of that
thread.Another even crazier scenario is if an event, mutex, or semaphore
lives in the stack space of a thread --
that would be very tricky to deal with for any threads that might be waiting
on it.

Nathan
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Ole Reinhardt-2]

Hi Rob!

> I know that in the history of NutOS killing threads has always been
> troublesome and I searched the archives to see what the current status was
> on this topic, without any new clues. Simply calling 'NutThreadKill' from
> the running thread doesn't work, at least that is my experience so far.

Just call NutThreadExit from the running thread or simply quit your
endless loop. In this case NutOS will remove the running thread from the
memory as soon as it was ended.

Another thing you should consider is to allocate memory dynamical from
the heap instead of reserving large stack space. So you could even save
memory within the context of a running thread as well.

Bye,

Ole Reinhadt



--
 _____________________________________________________________
|                                                             |
| Embedded-IT                                                 |
|                                                             |
| Ole Reinhardt        Tel. / Fax:        [phone] |
| Luisenstraße 29      Mobil:             [phone] |
| 57076 Siegen         eMail:    ole.reinhardt@... |
| Germany              Web:         http://www.embedded-it.de |
|_____________________________________________________________|

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Ethernut]

Ole Reinhardt wrote:

> Just call NutThreadExit from the running thread or simply quit your
> endless loop. In this case NutOS will remove the running thread from the
> memory as soon as it was ended.

Yes, and a related sample is available at
http://www.ethernut.de/nutwiki/Run_Once_Thread


Harald
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Rob van Lieshout (PragmaLab)]

Hi Morty,

> the main problem with killing threads is the memory
> management. You need to know which memory was allocated to
> which thread, so you can free it when you kill a thread.
> About a year ago I've written some code to do this and also
> sent some patches which partly made it into the Nut/OS
> codebase. If you are interested I can search that code.
> Shouldn't be too much trouble to add it to the current
> codebase, as HEAPNODE ist now used everywhere.
> Basically you have to add an thread-element and a
> next-element to HEAPNODE. When allocating you write
> current-thread to the memory and link it into the list (as
> with the debug-code). When killing a thread you need to walk
> the list and free all memory which isn't needed any more.
>
> I can also send you my Diploma Theses, which also describes
> this problem. It's in German, though.

I'll be more then happy to read more about the subject in your Diloma
Theses. German is OK (will take me a bit longer to read, but it will make me
realize that I didn't take my German lessons for nothing all those years).

In fact, I started to modify the NutOS code already to be able to 'find
back' the allocated blocks that got associated with the thread, but then
realized that someone else might had run into the same problem. If you could
share the specific code with me, it would be very much appreciated.

The struct itself (NUTTHREADINFO) doesn't seem to get removed either when
killing the thread, is it?

Thanks and best regards.....

Rob (info - at - pragmalab.nl)

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Nathan Moore-5]

>
>
>
> The struct itself (NUTTHREADINFO) doesn't seem to get removed either when
> killing the thread, is it?


The idle thread frees it, I believe.
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Rob van Lieshout (PragmaLab)]

Hi Harald and Ole,

> > Just call NutThreadExit from the running thread or simply quit your
> > endless loop. In this case NutOS will remove the running
> thread from
> > the memory as soon as it was ended.
>
> Yes, and a related sample is available at
> http://www.ethernut.de/nutwiki/Run_Once_Thread

Glad to hear that a methode is available. Just to be sure: with this method
no 'NutOS remainders' are left in RAM? Ofcourse the application itself is
responsible for freeiing the resources it claimed during executon of thread,
but it doesn't know about resources that the threadmanagement claimed. I
already figured out that the 'NUTTHREADINFO' structure is allocated in the
same block as the threadstack itself (and so altogether removed in one
action in 'NutThreadDestroy())'.

In other words, no known memory leak issues when constantly creating and
killing the same thread ?

Thanks.

Regards,

Rob van Lieshout

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Ole Reinhardt-2]

Hi Rob,

> In other words, no known memory leak issues when constantly creating and
> killing the same thread ?

Not that I know of. I use this kind of thread processing in one of our
applications without any known impact.

Bye,

Ole

--
 _____________________________________________________________
|                                                             |
| Embedded-IT                                                 |
|                                                             |
| Ole Reinhardt        Tel. / Fax:        [phone] |
| Luisenstraße 29      Mobil:             [phone] |
| 57076 Siegen         eMail:    ole.reinhardt@... |
| Germany              Web:         http://www.embedded-it.de |
|_____________________________________________________________|

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion