Úniky paměti při práci s POSIXovými vlákny (diskuse)

[Jardík]

A je to tu zase. Fakt nechápu, co je vede k použití typu long pro počítání počtu vláken... navíc je to o ničem. Dávat bacha na pthread_join je nedostatečné. Je třeba taky dávat bacha na leaky spojené s pamětí nealokované na stacku v kombinaci např. s pthread_exit, pthread_cancel, pthread_kill ...

[Andrej]

Jinými slovy, je prostě dobré vědět o pthread_cleanup_push a pthread_cleanup_pop.

[Luboš Doležel (Doli)]

To je hezký. Že thready používám na Linuxu 6 let, tak jsem tyhle funkce neznal, protože se na ně všude kašle, a to jsem toho v začátcích načetl

[Jardík]

tyhle funkce neznal

Pozor, s tímhle jsem měl problémy, někde to tu asi bude zahrabaný v dotazech - můžou to být makra a v GCC na linuxu@x86-64 to opravdu makra jsou.

[Jardík]

tady to je.

[Andrej]

No jasně, že jsou to makra. Právě proto, aby někdo nedělal takové prasečinky jako podmíněné pthread_cleanup_{push,pop} a hlavně aby to nezapomněl spárovat. Vždy se dá programovat tak, aby ta dvě volání byla spárovaná.

[Andrej]

Vlastně to nejsou funkce, ale (konkrétně na Linuxu) makra. To první končí { a to druhé začíná }. Aby to člověk nezapomněl spárovat.

Při použití podmínkových proměnných ve spojení s thread cancellation je tohle naprostá nezbytnost, protože zrušení vlákna při čekání na podmínkovou proměnnou vždy nakonec nechá mutex zamčený. A někdo ho musí odemknout. (V man pthread_cond_wait je o tom celý odstavec.)

[Luboš Doležel (Doli)]

Teď na to koukám. Teď už se mi to nezdá tak zajímavý.

[Andrej]

Možná to není zajímavé, ale jsou případy, kdy je to nezbytné. Típnout vlákno (pthread_cancel()), které čeká na podmínkové proměnné, prostě nelze nijak jinak než za asistence pthread_cleanup_*(). Jinak ten příslušný mutex už zůstane zamčený a není žádný korektní způsob, jak ho znova odemknout.

[the já]

Tím longem asi chtěli naznačit, že mají rychlé počítače

[Andrej]

Longem prostě vyjadřuji, že mám něco dlouhého a jsem na to hrdý.

[Aleš Janda]

Univerzální rada je - spustit to pod valgrindem, veškeré leaky uvedené v článku odchytí.