Created by Ahmad Abdelwahed
over 9 years ago
|
||
enter_region: TSL REGISTER, LOCK CMP REGISTER, #0 JNE enter_region RETleave_region: MOVE LOCK, #0 RETmutex_lock: TSL REGISTER, MUTEX CMP REGISTER, #0 JZE ok CALL thread_yield JMP mutex_lockok: RETmutex_unlock: MOVE MUTEX, #0 RETThe code of mutex_lock is similar to the code of enter_region but with a critical difference. When enter_region fails to enter the critical region, it keeps testing the lock repeatedly (busy waiting). Eventually, the clock runs out and some other process is scheduled to run. Sooner or later the process holding the lock gets to run and releases it.With (user) thread, the situation is different because there is no clock that stops threads that have run too long. Consequently, a thread that tries to acquire a lock by busy waiting will loop forever and never acquire the lock because it never allows any other thread to run and release the lock.That is where the difference between enter_region and mutex_lock comes in. When the later fails to acquire a lock, it calls thread_yield to give up the CPU to another thread. Consequently, there is no busy waiting. When the thread runs the next time, it tests the lock again.Since thread_yield is just a call to the thread scheduler in user space, it is very fast. As a consequence, neither mutex_lock nor mutex_unlock requires any kernel calls.
Want to create your own Notes for free with GoConqr? Learn more.