Changes for page Deadlock Prevention

Last modified by chrisby on 2023/11/28 19:17

From version 1.1
edited by chrisby
on 2023/11/26 19:18
Change comment: There is no comment for this version
To version 3.6
edited by chrisby
on 2023/11/26 19:34
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -1,15 +1,16 @@
1 1  Deadlocks can only occur if all four specific conditions are met. Therefore, strategies to prevent deadlocks focus on negating one of these conditions.
2 2  
3 -#### Mutual Exclusion (Mutex)
3 +| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
4 +| **Condition** | **Description** | **Solutions** | **Dangers** |
5 +| Mutual Exclusion / Mutex | When resources can't be used by mutual thread and there are less resources than threads. | 1) Use concurrently accessible resources like AtomicInteger. 2) Increase the number of resources until its greater or equal to the number of competing threads. 3 ) Check if every required resource is accessible before the task starts. | |
6 +| Lock & Wait | Once a thread acquires a resource, it will not release the resource until it has acquired all of the other resources it requires and has completed its work. | Before reservation of a resource, check its accessibility. If a resource is not accessible, release every resource and start from anew. |
4 4  
5 -* Description:
6 - * When resources can't be used by mutual thread and
7 - * there are less resources than threads.
8 -* Solutions:
9 - * Use concurrently accessible resources like AtomicInteger.
10 - * Increase the number of resources until its greater or equal to the number of competing threads.
11 - * Check if every required resource is accessible before the task starts.
8 +1) Starvation: A thread never achieves to reserve all required resources. 2) Livelock: Thread gets tangled up.
12 12  
10 +These two approach are always applicable but inefficient as it causes a bad performance. |
11 +| | | | |
12 +| | | | |
13 +
13 13  #### Lock & Wait
14 14  
15 15  * Description: