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