[OSy] Nekolik dotazu

[Jiří Tlach]

Zdravim,

mel bych nekolik dotazu resp. pripominek:

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.


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.


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.


4) Dotaz ohledne podivneho chovani gcc pro MIPS pri kompilaci funkce s promennym poctem parametru.

Vsiml jsem si, ze gcc pro MIPS preklada tento C kod:

     void foo(const char *fmt, ...)
     {
     }

jako

    sw       a1, 4(sp)
    sw       a2, 8(sp)
    jr          ra
    sw       a3, 12(sp)

To znamena, ze aniz by si tato funkce naalokovala nejaky prostor na zasobniku, zapisuje registry a1,a2,a3 nad vrchol sveho
zasobniku a pristupuje tak v polozkam, ktere si na zasobnik ulozila funkce, ktera ji volala. Z tohoto chovani usuzuju, ze
pro funkce s vypustkou (tj. "..." - ten promenlivy pocet parametru) se jedna pravdepodobne o nejakou konvenci gcc prekladace,
a ze rutina volajici funkci s vypustkou pro ni nejprve pripravi "pudu" (tj. naalokuje nejake polozky na zasobniku) a teprve pak
ji zavola. 

Za obvykle situace, kdyz mam rutinu s mnoha prikazy a mezi nimi je volani napr. printk(), coz je funkce s vypustkou, tomu
tak skutecne je. Problem vsak nastava v situaci, kdy rutina vola nejakou funkci s vypustkou jako svuj posledni nebo
jediny prikaz. Pak totiz veskere alokace zasobniku zahadne zmizi a je tam rovnou skok na volanou funkci. Viz nasledujici kod:

    void myfunc(void)
    {
        printk("abc");
    }

se prelozi jako:

    lui       a0, 0x0                  /* zde linker misto 0x0 doplni hornich 16 bitu adresy retezce "abc" */
    j          printk                     /* nepodmineny skok na printk */
    addiu a0, a0, 0               /* zde linker misto 0 doplni dolnich 16 bitu adresy "abc" */

Toto chovani gcc mi vadi hlavne tehdy, pokud si funkci 'myfunc' zvoli nejake vlakno jako obsluznou rutinu
sveho casovace. Pak kdyz tuto rutinu z kernelu volam, ukladam si na zasobnik vlakna dulezite informace, 
ktere umozni po ukonceni obsluzne rutiny casovace pokracovat vlaknu v normalnim behu. Funkce printk() mi
proste prvnich 12 bytu techto mych informaci premaze a vlakno diky tomu po ukonceni obsluzne rutiny spadne.

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.

 Jiri Tlach