Zdravim :-)<br><br>prave riesime ako navrhnut mutexy tak, aby vyhovovali zadaniu a narazili sme na par problemov/otazok.<br><br>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 :)
<br><br>Tym padom sa teda po nas ziada nakodit mutexy "znovu" bez pouzitia disable_interrupts, ale miesto toho pouzit napr. spinlock... Je tam jeden (typicky :)) problem zamykani, ale ten sa da vyriesit specialnym atomickym volanim (syscallom) - odomknut spinlock (resp. nastavit hodnotu na nejakej adrese) +thread_suspend...
<br><br>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?<br><br>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 :)
<br><br>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... ;-(<br><br><br>Hm, ked to tak teraz po sebe citam, dufam ze to nie su prilis trivialne otazky :-)
<br><br><br>Andrej<br>