[OSy] Nekolik dotazu

[Martin Decky]

Hezky den,

> 1) Pripominka ohledne assignment testu a DEBUG_MUTEX symbolu.
> 
> Nasel jsem maly technicky problem v testu mutex5. Ve zdrojaku test.c tohoto testu se definuje symbol DEBUG_MUTEX s hodnotou 1. 
> To ma zajistit, ze nase implementace mutexu bude hlidat, aby mutex odemknulo pouze to vlakno, ktere ho zamknulo. Jinak se vypise panic.
> 
> Problem je v tom, ze definice tohoto symbolu musi byt viditelna pro zdrojovy soubor s implementaci mutexu. To ale zrejme nelze 
> zajistit jinak, nez natvrdo specialne pro tento test opravit nasi implementaci mutexu tim, ze do ni rucne vlozime 
> #define DEBUG_MUTEX 1 nebo vlozime pomoci #include nejaky specialni hlavickovy soubor, kde tato definice bude napsana. 
> To mi pripadne jako celkem neelegantni, nezapada to do automatizovaneho prekladu a spousteni vsech assignment testu a 
> chtel bych se proto ostatnich zeptat, zda nekdo nema nejaky lepsi navrh.

Lepsi navrh je nemenit implementaci na zaklade DEBUG_MUTEX, ale zmenit 
jen sadu funkci, ktera se bude volat. To lze udelat v hlavickovem souboru.

> 2) Dotaz ohledne delky testu.
> 
> Chtel bych se zeptat, jak dlouho ma u funkcniho kernelu trvat assignment test condvar1. Tento test vytvori 130 vlaken mezi nimiz jsou 
> producenti a konzumenti, kteri zamykaji a odemykaji mutexy a pouzivaji navic jeste podminkove promenne. Ani po 2 hodinach
> behu tento test na nasem kernelu neskoncil. Ale pro mensi pocet (napr. 52) vlaken probehne test behem par sekund a uspesne 
> skonci. Takze ted nevime, zda mame hledat chybu v nasem kernelu nebo vyzkouset cekat dele nez ty zminene 2 hodiny na 
> dobehnuti testu pro 130 vlaken.

Test i pri 130 vlaknech pobezi radove stejnou dobu jako pri tech 52 
vlaknech (na beznem dnesnim hardwaru ne dele nez desitky sekund), takze 
se nejspis jedna o problem ve Vasem kernelu.

> 3) Dotaz ohledne assignment testu timer1.
> 
> Z tohoto testu nelze poznat, jaky je mysleny vztah mezi casovaci (timery) a uspanym vlaknem. Nase implementace napriklad funguje
> tak, ze je-li vlakno zablokovane na synch. primitivu nebo je uspane pomoci thread_sleep/thread_usleep, pak se vyvolani casovacu,
> ktere si vlakno vytvorilo, odklada az do te doby, nez je opet odblokovano resp. probuzeno. Takze bych se chtel zeptat, jestli takove 
> chovani vyhovuje assignment testu timer1.

Tento problem je dost podobny tomu, ktery jsme zde jiz jednou 
diskutovali, viz 
http://nenya.ms.mff.cuni.cz/pipermail/osy/2006-October/000307.html

Osobne nemam na vec vyhraneny nazor, takze semantiku timeru, kterou jste 
implementovali, zdokumentujte.

> 4) Dotaz ohledne podivneho chovani gcc pro MIPS pri kompilaci funkce s promennym poctem parametru.
> 
> Resenim je samozrejme naalokovat si na zasobniku o 12 bytu vice, ale to neni systemove opatreni. Proto 
> by me zajimalo, zda je mozne toto podivne chovani gcc prekladace v prepinacich nejak nastavit nebo nejak jinak
> ovlivnit. Zadny odpovidajici prepinac jsem zatim nenasel.

Ten pozadovany prepinac je -fno-optimize-sibling-calls. Myslim si ale, 
ze nez menit chovani prekladace je lepsi precist si presnou specifikaci 
ABI pro volani funkci s promennym poctem parametru a podle toho pozmenit 
Vase inicialni nastaveni zasobniku.


M.D.