[OSy] Je MSIM deterministicky?

[Robert Sisaj]

Sypem si popol na hlavu, Ondrej to uhadol presne. Ale tu sa aspon ukazuje,
ze mailing list je skvela vec. No takze mozem ist spokojne hladat chybku v
nasom kerneli.

Este raz dakujem vsetkym zucastnenym za pohotove a trefne reakcie.

Robo

2009/12/4 Martin Decky <decky at dsrg.mff.cuni.cz>

> Konkretne sa pri vykonavani tohoto kodu pouziva 1 cpu, pamat a potom uz
>> len dprinter a dtime.
>>
>
> A ten dtime Vam neprijde vubec podezrely? Vzdyt odvozuje cas od hodin
> realneho casu hostujiciho systemu, coz urcite neni prilis deterministicke
> zarizeni (mira je determinismu je primo ovlivnena tim, jak deterministicky
> se chova Vas nativni OS a dalsi procesy, ktere bezi paralelne s MSIMem a
> ovlivnuji jeho planovani).
>
>  Orezat to na mensi kus, pri ktorom sa nedeterminizmus prejavi bude
>> zrejme problem :-( Toto chovanie vidim prvykrat, prejavilo sa mi to s
>> nasim kernelom pri teste map2 z AS2.
>>
>> [...]
>>
>>
>> Mierny zasah do kodu kernelu tento nedeterminizmus odstranil (resp. test
>> presiel zakazdym tak ako mal). Ten zasah z pohladu testu (msimom
>> skutocne vykonavaneho kodu) je IMHO neviditelny, prakticky by mala byt
>> len o nieco vacsia binarka kernelu a cast kodu teda lezi na inych
>> adresach.
>>
>
> Specialne pokud se jedna o memory management, tak root cause vubec nemusi
> byt v casovem nedeterminismu, i kdyz ani to samozrejme nelze vyloucit (race
> conditions jsou zkratka nevyspitatelne). Spis bych to videl tak, ze ten
> casovy nedeterminismus muze obcas zafungovat jako nahodny trigger chyby ve
> Vasem kodu.
>
> Pokud se ale chovani kodu napadne meni pri zmene memory layoutu kernelu
> (coz vede k tomu, ze data jsou najednou na jinych adresach), tak se
> setkavate s naprosto typickym projevem chyb memory managementu, ktere jsou
> zpusobeny spatnou pointerovou aritmetikou, buffer overrunem, pretecenim
> promennych apod. Zkratka tam asi mate nejakou memory-related chybu, ktera se
> neprojevi hned na tom miste, kde se stane, ale potencialne az mnohem
> pozdeji.
>
>
>
> M.D.
>
> _______________________________________________
> OSy mailing list
> OSy at dsrg.mff.cuni.cz
> https://dsrg.mff.cuni.cz/mailman/listinfo/osy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://d3s.mff.cuni.cz/pipermail/nswi004/attachments/20091204/53ea5b4f/attachment.html>