[OSy] rwlocky + mutex

Lubomír Bulej lubomir.bulej at mff.cuni.cz
Thu Oct 21 18:00:13 CEST 2004


Dobry den,

>1.) Chcel by som sa opytat preco je nutne definovat obidve nasledujuce
>funkcie:
>    * void rwlock_write_unlock (struct rwlock * rwl)
>    * void rwlock_read_unlock (struct rwlock * rwl)
>Vacsinou pri danom type zamku sa pouziva len jedna funkcia unlock a ta
>odomkne zamok (znizi pocet citajucich, ak je 0 prebudi niekoho z fronty
>alebo nastavi writers na false a pripadne prebudi niekoho z fronty)
>
>  
>
Samozrejme se to taky tak da udelat. Na druhou stranu oddelene funkce
jsou parove k operacim lock, tedy vysledkem je potencialne citelnejsi kod
uzivatele zamku. Da se navic kontrolovat, zda uzivatel zamku odemyka
zamek pro stejny rezim, pro jaky zamek zamknul.

Nic Vam samozrejme nebrani v tom udelat implementaci v jedne funkci
a pro "nase" API pouzit makra.

>2.) Dalej by som sa chcel opytat, ci ma zamok pustit ziadosti o citanie vzdy,
>ak je prazdna fronta ziadosti, v opacnom pripade zaradit ziadost do fronty. 
>A v pripade vyberania z fronty prebudit najdlhsiu suvislu postupnost
>ziadosti na citanie.
>RRRRWWRRWRRRRR sa spracuje (RRRR) (W) (W) (RR) (W) (RRRRR)
>
>  
>
Neni mi uplne jasne, na co se ptate v prvni casti otazky -- pokud je 
fronta zadosti
prazdna a zamek odemcen, neni duvod blokovat vlakno, ktere se snazi zamek
zamknout.

Co se druhe casti tyce, nezapomente, ze zamky jsou rekurzivni. K zajisteni
fairness (a tedy probouzeni v poradi jake popisujete) v tomto pripade byste
musel pravdepodobne alokovat pamet pri zamykani, coz neni dobre.

>3.) Co sa ma udiat ak je definovane makro DEBUG_MUTEX a mutex sa snazi
>odmknut ine vlakno? Ma sa vyvolat panic alebo iba urobit kprint...?
>
>  
>
Vyvolejte panic.


Lubomir Bulej




More information about the NSWI004 mailing list