Skip to Content

Changes for page Deadlock Prevention

Last modified by chrisby on 2023/11/28 19:17
From version 4.1
edited by chrisby
on 2023/11/26 19:35
Change comment: Rollback to version 3.5
To version 1.4
edited by chrisby
on 2023/11/26 19:29
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -1,11 +1,11 @@
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 -| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
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. | Starvation: A thread never achieves to reserve all required resources. Livelock: Thread gets tangled up. These two approach are always applicable but inefficient as it causes a bad performance. |
7 -| | | | |
8 -| | | | |
3 +| ------------- | --------------- | ------------- | ----------- |
4 +| **Condition** | **Description** | **Solutions** | **Dangers** |
5 +| | | | |
6 +| | | | |
7 +| | | | |
8 +| | | | |
9 9  
10 10  #### Lock & Wait
11 11