Skip to Content

Changes for page Deadlock Prevention

Last modified by chrisby on 2023/11/28 19:17
From version 4.3
edited by chrisby
on 2023/11/26 19:38
Change comment: There is no comment for this version
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 shared between threads and there are fewer resources than threads. | 1) Use concurrently accessible resources such as AtomicInteger. 2) Increase the number of resources until it is greater than or equal to the number of competing threads. 3) Check if each required resource is accessible before starting the task. | |
6 -| Lock & Wait | Once a thread has acquired a resource, it will not release it until it has acquired all the other resources it needs and has completed its work. | Before reserving a resource, check its availability. If a resource is unavailable, release all resources and start over. | 1) Starvation: A thread never manages to reserve all the resources it needs. 2) Livelock: The thread gets tangled up. →These two approaches are always applicable, but inefficient because they cause bad performance. |
7 -| | | | |
8 -| | | | |
3 +| ------------- | --------------- | ------------- | ----------- |
4 +| **Condition** | **Description** | **Solutions** | **Dangers** |
5 +| | | | |
6 +| | | | |
7 +| | | | |
8 +| | | | |
9 9  
10 10  #### Lock & Wait
11 11