1. Nested Mutex Design Document and Proposed Solution

2. Important TCB DS Priority_Control Current_Priority; Priority_Control Real_Priority; Int32_t resource_count; #if Strict order Chain_Control lock_mutex

3. Mutex Control Block related DS Core_Mutex_Attributes: - Priority_Inheritance - Priority_ceiling Core_Mutex_Order_List: - Chain_Node lock_queue; - Priority_Control priority_before; Core_Mutex_Control: - Core_Mutex_Attribute Attr.. - Thread_Queue_Control wait_queue; - nest_count - Thread_Control *holder #if strict order - Core_Mutex_Order_list queue

4. Relation Between Thread and Mutex Chain_Control lock_mutex(in TCB) - Chain_Node Node - Chain_Node *fill Core_Mutex_Order_list queue(in MCB) - Chain_Node lock_queue; - Priority_Control priority_before; Chain Structure to manage nested mutex and priority inheritance cases: Lock_mutex (holder thread) NodeFillqueue (m1)Lock_queueP_before PrevNext queue(m2) Lock_queueP_before queue(m3) Lock_queueP_before PrevNextPrevNext

5. Mutex Locking Mechanism _API_Mutex_Lock() (apimutexlock.c) _Core_Mutex_Seize() (coremuteximpl.h) _Core_Mutex_Seize_Body() (coremuteximpl.h) trylock_body()

6. Mutex_Attributes Mutex_State Thread tries to acquire mutex MutexAvailableFIFO - Set holder - inc rsc_count - nest_cnt:=1 (Successfully Acquired the lock) Strict_Order - Set holder - inc rsc_count - nest_cnt:=1 Prepend Mutex’s DS in Chain Structure, set priority_before, Successfully acquired mutex Ceiling Does not care much of it now. Not AvailableRe-entrantNesting Behavior - Allowed - NA - POSIX - Blocks

7. Implementation and Test Cases M1M2M3M4M5M6M7M8M9M10 888888888W Mutex Acquired Priority_before Chain Structure for strict order mutex Thread T1 is the holder thread for all mutexes having real and current priority = 8 has acquired above mutexes and now is waiting on mutex M10

8. Thread T2 of priority=1(highest) tries to acquire mutex m5 which is already acquired by the thread 1 - Following action takes place: - Current Priority of T1 escalates to 1. - re-enqueued T1 with updated priority. State: T1.Current_priority = 1 (This is the current implementation of rtems which leads to nested mutex problem in priority inheritance problem. Problem occurs because instead of checking priority_before of thread T1 while it acquired mutex m5 we check the current priority of thread T1) Now in next slide I explain my solution----  M1M2M3M4M5M6M7M8M9M10 888888888W

9. Solution Algorithm We should check the recorded priority_before of mutex m5 while it was acquired by thread T1 rather than checking its current_priority. This will help us in proper step down of priorities. Mx.priority_before < T2.current_priority Escalate priority_before for all mutex acquired after M5 which satisfies above condition. This ensures proper step down while releasing mutexes. Do Nothing. Current code properly enqueues T2 according to its priority in wait queue M1M2M3M4M5M6M7M8M9M10 888881111W Updated Chain Structure True False

10. A new thread T3 of priority=4 tries to acquire mutex m3 which is again already acquired thread T1. So according to algorithm the state will become: Now a new thread T4 of priority = 3tries to acquire mutex M5. So according to algorithm all mutex ahead of M5 will be tested. As M6.priority_before < T4.current_priority evaluates false, therefore no change happen to chain structure. It will be inserted to wait_queue of M5 according to its priority. No Change M1M2M3M4M5M6M7M8M9M10 888441111W M1M2M3M4M5M6M7M8M9M10 888441111W

11. Now a new thread T5 of priority = 3 tries to acquire mutex M4. So according to algorithm all mutex ahead of M5 will be tested As M5.priority_before < T4.current_priority evaluates True we iterative update the chain structure. I guess I have covered all the test scenarios from my end. Please let me know if you come up with any other test-cases which fails the solution. Algorithm Analysis: Cost of Updation: O(n) n -> Number of mutex acquired by the holder thread. Should not be the problem as thread won’t acquire so many mutex. Algorithm should work smoothly and efficiently. Also let me know when the efficiency will break in multi-processor case. I don’t feel there should be any problem for that with this solution. M1M2M3M4M5M6M7M8M9M10 888431111W