C: Memory Pools, wie und wo definieren?

[ichbinblöd (Gast)]

Hallo.
Memory Pools überfordern mich im Moment noch, ich muss sie aber 
einsetzen da sonst mein RTOS säuerlich reagiert (Buffer underflow wegen 
malloc).
Ich bin mir jetzt noch nicht sicher welches Konzept ich verwenden soll 
und ob ich überhaupt verstanden habe wie Memory Pools überhaupt zu 
verwenden sind.
Soweit ich verstanden habe ist der Vorteil dass ein Memorypool aus einer 
bestimmten Struktur der Speicherinhalte besteht.Also sollte ich einen 
Pool für alle gleichen Inhalte verwenden.
In meinen Fall habe ich z.B. zwei Module beispielsweise

usart_handler.c

und

debug_interface.c

beide brauchen einen Stringbuffer dessen Länge noch nicht feststeht und 
erzeugen damit einen Block mit Datentyp char.
In meinem Fall (cmsis-rtx) wäre ein passender Pool:

osPoolDef(char_pool,8,char);

siehe: 
http://www.keil.com/pack/doc/cmsis_rtx/group___c_m_s_i_s___r_t_o_s___pool_mgmt.html#ga87b471d4fe2d5dbd0040708edd52771b

Jetzt frage ich mich: soll ich einen Pool für char-Datentypen erstellen 
und dann in den Modulen Blöcke reservieren lassen?
Der Pool wäre dann ja Global.
Wo müsste ich ihn dann Definieren?
zur Info: ich benutze eine datei global.h , die alle möglichen Globalen 
includes beinhaltet. Dort könnt ich also

osPoolDef(char_pool,8,char);
osPoolId pool_id;

reinhauen. Den Pool muss ich aber auch kreieren mit

pool_id = osPoolCreate(osPool(char_pool));

nur wo soll das hin? pool_id müsste dann ja global verfügbar sein? 
Eventuell steh ich aber auch nur schwer auf der Leitung.

Mein Gedankenansatz war folgender: osPoolCreate darf nur einmal 
ausgeführt werden, deswegen ist es im Modul unzulässig. oder nicht?

[Vlad T. (vlad_tepesch)]

ich würde eine header und c Datei Pools.[hc] machen und da für die 
unterschiedlichen Typen die Pools definieren.
es macht in meinen Augen aber absolut keinen Sinn char pools der größe 8 
zu definieren. da lohnt sich der Overhead ja nicht. bei so wenig bytes 
kannst du auch den Puffer privat für das Modul statisch definieren, was 
ich sowieso bevorzugen würde. dynamische Allocation hat imho in 
kleineren Steuergeräten nix zu suchen.

[ichbinblöd (Gast)]

danke! die id müsste ich dann mit
extern
in meine Module laden.
Ja 8 ist eventuell zu klein :)
war nur ein Beispiel

[ichbinblöd (Gast)]

Vlad Tepesch schrieb:
> dynamische Allocation hat imho in
> kleineren Steuergeräten nix zu suchen.

das Problem ist dass ich fast den Ganzen Speicher kurzzeitig brauche und 
dann für einige Textverarbeitung an anderer Stelle keinen Platz mehr 
haben werde.

[Vlad T. (vlad_tepesch)]

ichbinblöd schrieb:
> das Problem ist dass ich fast den Ganzen Speicher kurzzeitig brauche und
> dann für einige Textverarbeitung an anderer Stelle keinen Platz mehr
> haben werde.

dann löse das Problem so, dass du den Routinen einen Speicherbereich 
übergibst, den sie temporär verwenden dürfen, ohne Annahmen machen zu 
dürfen, was vorher drin steht und hinterher damit passiert.

Das verhindert, dass vergessen wird den Puffer zurückzugeben, oder dass 
der Speicher fragmentiert.

[ichbinblöd (Gast)]

dann müsste ich mir den speicherbereich ja trotzdem vorher reservieren, 
oder?

[Vlad T. (vlad_tepesch)]

ichbinblöd schrieb:
> dann müsste ich mir den speicherbereich ja trotzdem vorher reservieren,
> oder?

klar, aber ich würds statisch machen.

edit: die Frage ist halt, lässt sich dein Problem darauf abbilden.
wenn du das Bedürfnis hast jeweils unterschiedlich große Teile dieses 
temporären Speicher zu behalten, kommst du um die Pools vielleicht nicht 
drum rum. Wenn es wirklich nur um temporären Arbeitsspeicher geht und 
der zu groß für den Stack (vielleicht reicht ja auch eine automatische 
Variable) ist, würde ich es so, wie von mir beschrieben machen.
Der Memorypool macht vermutlich auch nix anderes, als einen statisches 
Array anzulegen. Zusätzlich wird er aber noch eine Art Belegungskarte 
pflegen, da ja beliebig unterschiedlich Große Teile dieses Pools 
angefordert und wieder freigegeben werden können, was für dein Problem 
ja scheinbar nicht notwendig ist.