[OSy] zadanie 3 - mutexy

[Martin Decky]

> Hlavny je ten, ze predpokladame ze mutex_lock atd. by nemal byt len stub
> za nejaky syscall, ktory by volal priamo dane funkcie v jadre...
> Spravne? V opacnom pripade by to bolo vcelku trivialne :)

V drivejsich letech jsme implementace, kde vsechny operace nad
synchronizacnimi primitivy byly samostatne syscally, povazovali za
dostacujici. I tak to totiz neni uplne trivialni, napriklad je velmi
nevhodne, aby kernel daval uzivatelskemu procesu volne k dispozici
samotnou datovou strukturu synchronizacniho primitiva.

Elegantnejsi cesta (kterou ocenujeme lepsim bodovym ohodnocenim) je
implementovat synchronizacni primitiva v uzivatelskem prostoru prevodem
na kernelove prostredky pro planovani vlaken (povolovani/zakazovani
preempce, fronty cekajicich vlaken atd.). Pouziti spinlocku ma
opodstatneni az na viceprocesorovych systemech.

> Ale aj toto riesenie ma potom hacik - nie prilis lahke medziprocesove
> pouzitie (kedze "data" toho mutexu budu vo VMA  toho jedneho procesu...)
> Nebude to vadit?

Zadani nehovori o zadnem sdileni pameti mezi uzivatelskymi procesy,
takze nevim, jak si presne predstavujete to meziprocesove pouziti a
k cemu by vlastne melo slouzit ..

> Este potom ostava problem (s cisto user mode mutexmi), ako poriesit
> casovace - kedze tie v zadani nie su, asi by sme si ich do neho museli
> pridat... Alebo to vyriesit cez nejake nove vlakno vyrabane pri zamykani
> cez mutex_lock_timeout - ale to mi pride dost nepekne riesenie :)

Vhodne pouziti kernelovych casovacu je v poradku. At uz je pouzijete
neprimo prostym prevodem uzivatelskych mutexu na kernelove, nebo nejakym
sofistikovanejsim zpusobem.

> Este jedna otazka - nevadi, ked thread_create() atd. su riesene ako
> stub-y za syscally, ze? Naprogramovat "dalsie" vlakna v user mode, to by
> asi dalo dalsich par dni prace... ;-(

User-managed vlakna skutecne nepozadujeme. Troufal bych si dokonce
tvrdit, ze pokud maji byt preemptivni, tak se bez nejake podpory v jadre
naprogramovat nedaji.


M.D.