Changes for page Deadlock Prevention

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -1,16 +1,8 @@
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		-|
5		-
6		-###### Condition |
7		-
8		-###### Description |
9		-
10		-###### Solutions |
11		-
12		-###### Dangers / Problems |
13		-| **1) 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. | |
14		-| **2) 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. |
15		-| **3) No Preemption** | A thread is unable to steal a resources reserved by another thread. | A thread is allowed to ask another thread to release all of its resources (including the required one) and starting from anew. This approach is similar to the 'Lock & Wait' solution but has a better performance. | |
16		-| **4) Circular Waiting / Deadly Embrace** | When two or more threads require a resource which is already reserved by another of these threads. Example: Thread T1 has resource R1 and waits for R2 to be released. Thread T2 has resource R2 and waits for R1 to be released. | All threads reserve all resources in a the same order. | 1) The order of reservation doesn't necessarily have to be the same as the order of usage. This leads to inefficiencies like reserving a resource at the beginning which is just required at the end of the task. 2) Unnecessarily long locked resources. 3) Order can not always be specified. |
	3	+| -------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
	4	+| **Condition** | **Description** | **Solutions** | **Dangers / Problems** |
	5	+| 1) 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	+| 2) 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	+| 3) No Preemption | A thread is unable to steal a resources reserved by another thread. | A thread is allowed to ask another thread to release all of its resources (including the required one) and starting from anew. This approach is similar to the 'Lock & Wait' solution but has a better performance. | |
	8	+| 4) Circular Waiting / Deadly Embrace | When two or more threads require a resource which is already reserved by another of these threads. Example: Thread T1 has resource R1 and waits for R2 to be released. Thread T2 has resource R2 and waits for R1 to be released. | All threads reserve all resources in a the same order. | 1) The order of reservation doesn't necessarily have to be the same as the order of usage. This leads to inefficiencies like reserving a resource at the beginning which is just required at the end of the task. 2) Unnecessarily long locked resources. 3) Order can not always be specified. |