malloc/free

Jaroslav Buchta jaroslav.buchta na hascomp.cz
Čtvrtek Listopad 3 11:34:29 CET 2016


sprintf by snad melo byt thread safe, pokud se synchronizuji tyto 
alokacni funkce (ktere to asi vetsinou pouziva) a pouzije spravna verze 
knihoven + obsluha kontextu pri prepinani vlaken.
Aspon ja jsem ve FreeRTOS na problem nenarazil.
Z prosteho ISR to samozrejme volat (bez vyse uvedenych nalezitosti) 
nejde.To asi neni dobry napad ani co se tyce dyn. alokace, uz proto, ze 
to pomerne dlouho a nepredvidatelne ruzne trva.
A zrovna ten FreeRTOS kde se musi setrit a zasobniky delat na miru je 
pripad, kdy se to malloc/free na vetsi buffery hodi, protoze to bere ze 
spolecne pameti a da se osetrit, kdyz treba zrovna nebude docasne k 
dispozici kvuli jinym threadum.

Dne 03.11.2016 v 11:10 Jiří Nesvačil napsal(a):
>
>>> - alokace docasnych objektu (buffery pro sprintf, komunikaci...) s 
>>> velmi
>>> kratkou zivotnosti, treba jen behem jedne funkce
>> Na toto sa hodi alloca() aj ked samozrejme aj tam treba vediet co clovek
>> robi.
>>
>> Mimochodom, sprintf() u mna spada tiez do kapitoly "taky to funguje". A
>> niektore (pomerne bezne pouzivane) kniznice k *printf() pribalia svoj
>> dynamicky alokator, cim sme sa pekne zacyklili...
>>
>> wek
>
> To bude zalezet od aplikace. Pokud na malem cpu mate nejake OS, tak 
> musi myslet na to, ze kazde vlakno bude potrebovat vetsi stack k vuli 
> temto metodam, spise vyuzijete heap a stack nechate maly.
>
> sprintf neni thread safe a za to existuji nahrady i bez zamku a s 
> nejakym limitem.
>
> Jirka
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list




Další informace o konferenci Hw-list