[OSy] zadanie 3 - mutexy

[Andrej Kruták]

> 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.
>

Asi to spravime tymto sposobom teda....

Jedina otazka v tomto emaile :-) :

Je jasne, ze nechat data v pamati pristupnej z user space nie je dobry napad
- potom tu ale vznika jeden celkom problem... Totiz, mutex_init logicky musi
inicializovat nejaku strukturu - ale kedze uzivatelsky proces tu pamat
nemoze poskytnut, je nutne ten mutex naalokovat v kernel pamati - co 1) moze
zlyhat, 2) tak moze user process v pohode zabit jadro. Bol by velmi "proti
pravidlam" vyrobit mutex_init, ktory by mohol aj zlyhat? (i.e. vratit
ENOMEM)


> 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.
>
Takto by sme to ovela radsej spravili, ale uz tak je toho casu malo - robit
toto + rozsirene zadanie + sa ucit na ostatne skusky a zapocty nie je tak
uplne "trivialne" ;-( Mozno po skuskovom v ramci vlastnej zabavy :)



> 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 ..
>
To bol tiez len taky perfekcionisticky napad :) Beriem spat...


Andrej Krutak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://d3s.mff.cuni.cz/pipermail/nswi004/attachments/20080104/bc9dfb3d/attachment.html>