Ladeni multithreadove aplikace

Stanislav Meduna stano na trillian.eunet.sk
Sobota Leden 22 14:51:27 CET 2000


On 21 Jan 2000 23:09:17 +0100, Michal Krause wrote:

:> Pokud se promenna cte bez zamku, tak se musi dat volatile, jinak
:> hrozi, ze to kompilator nejak preoptimalizuje. Taky je treba brat
:> zretel na to, ze na SMP jeden procesor vidi zapisy druheho zpozdene;

: Huh, zacinam mit pocit, ze jsem docista mimo. A to nemam rad :)

No a preto radsej zamykaj poctivo a nespekuluj nad tym,
ze "toto je urcite atomicke a ak budu pristupy v tomto
poradi, tak zamykat netreba". Robia sa aj take triky,
ale to nechaj Linusovi a spol. do jadra a svoje programy
rob radsej konzervativne :-)

:> cteni a zapisy jednoho procesoru muzou byt navic ruzne prehazovany.

Toto AFAIK nie je pravda (siel o tom pred casom znacne
technicky thread v l-k, kde islo o usetrenie par
cyklov v spinlockoch). Procesor sice moze interne
urobit reordering instrukcii, ale nemoze si dovolit
triky, ktore je vidno na jeho rozhraniach. Dovodom
je to, ze obsahy cache oboch procesorov musia
byt bezpodmienecne synchronne. Takze ak kod
zapisuje najprv A a potom B, iny procesor nemoze
vidiet najprv zapis B a potom A. Nie som si uplne
100% isty, ale to bol tusim vysledok tej diskusie.

: Co pujde, nacpu radeji do lokalnich promennych (pametove naroky tim
: nijak extremne nevzrostou) a zbytek dusledne obklicim mutexy.

A viac-menej o toto aj v MT aplikaciach ide. Hacky sa hodia az na
situaciu, ked vsetko chodi a je jasne, ze je konkretny
kus kodu bottleneckom.

Z tejto diskusie mam pocit, ze si do MT vhupol rovnymi
nohami a nejaky teoreticky background prilis nemas.
Ak je to tak, mozno by nebolo marne zohnat si nejake
skripta (konkretne zial odporucit neviem) a precitat
si vseobecny pokec o synchronizacii, typoch synchronizacnych
primitiv, kedy sa ktora hodi, postupy pre zabranenie
deadlockom a.p. To sa neda prilis vysvetlit v niekolkych
clankoch v newsgrupe...

Zdravi
-- 
					Stano



Další informace o konferenci Linux