[MWy] Chimera deadlock

[Karel Fiser]

Ono by stacilo, kdyby pthread mutexy byly rekurzivni.
Problem totiz nastane (u meho konkretniho prikladu), kdyz se vlakno v upcallu snazi
zamknout (jiz zamknuty) mutex pri vyhledavani cesty.
Konkretne zde:
Pri volani fce route_lookup (state, key, count, is_safe) at route.c:169
pri zamykani routeglob->lock na radce 177.
Tento mutex je nejspis jiz zamceny v obsluze upcallu.
Kdyby tento mutex byl rekurzivni, nic nebrani cestu vyhledat.

Nejlepsi by bylo tento problem asi vyresit primo v chimere, coz je pro nas ucel nejspis nepripustne.

Napad se zvlastnim vlaknem je podle me super, nemelo by ale urcite cekat aktivne.
Pouziti semaforu (napr. implementovaneho v chimere) nebo primo pthread conditional vars by byl jiste lepsi.

Vzhledem k tomu, ze chimera uz ma mechanismus s poolem vlakem, frontou jobu a semaforem na ni,
bylo by asi vubec nejlepsi tento mechanismus vyuzit. Vyznat se ale ve zdrojacich je celkem komplikovane,
protoze radi pouzivaji void * ikdyz ho hned ve fci pretypuji (nevi nekdo proc takovou zvracenou techniku pouzivaji?).
O dokumentaci ani nemluvim, ta jakoby nebyla.

Pokud ma nekdo lepsi napad, sem s nim, ja se nejspis vydavam cestou vyuziti job_queue a mechanismu chimery okolo ni,
ale nejsem si jist, jestli to neni prilis vynalozene energie zjistovat vyznam dabelskeho callbacku se signaturou
void (*FuncPtr) (void *, void *);
a registracni fce void job_submit(List * job_q, FuncPtr func, void * args, int args_size)

Dne 26.4.2011 17:50, Krystof Vasa napsal(a):
> Ted to resim take a vyresim to globalni promennou a vlaknem, ktere bude kazdou vterinu kontrolovat tu promennou. Je to kanon na vrabce, ale asi nejjednodussi zpusob, jak to obejit.
>
> K.
> _______________________________________________
> MWy mailing list
> MWy at d3s.mff.cuni.cz
> https://d3s.mff.cuni.cz/mailman/listinfo/mwy
>