Wiki source code of Deadlock Prevention
Hide last authors
| author | version | line-number | content |
|---|---|---|---|
 |
1.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 | |||
| 3 | #### Mutual Exclusion (Mutex) | ||
| 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. | ||
| 12 | |||
| 13 | #### Lock & Wait | ||
| 14 | |||
| 15 | * Description: | ||
| 16 | * 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. | ||
| 17 | * Solutions: | ||
| 18 | * Before reservation of a resource, check its accessibility. | ||
| 19 | * If a resource is not accessible, release every resource and start from anew. | ||
| 20 | * Dangers: | ||
| 21 | * Starvation: A thread never achieves to reserve all required resources. | ||
| 22 | * Livelock: Thread gets tangled up.→ This approach is always applicable but inefficient as it causes a bad performance. | ||
| 23 | |||
| 24 | #### No preemption | ||
| 25 | |||
| 26 | * Description: | ||
| 27 | * A thread is unable to steal a resources reserved by another thread. | ||
| 28 | * Solution: | ||
| 29 | * 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. | ||
| 30 | |||
| 31 | #### Circular Waiting / Deadly Embrace | ||
| 32 | |||
| 33 | * Description: | ||
| 34 | * When two or more threads require a resource which is already reserved by another of these threads. | ||
| 35 | * Example: | ||
| 36 | * Thread T1 has resource R1 and waits for R2 to be released. | ||
| 37 | * Thread T2 has resource R2 and waits for R1 to be released. | ||
| 38 | * Solution: | ||
| 39 | * All threads reserve all resources in a the same order. | ||
| 40 | * Problems: | ||
| 41 | * 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. | ||
| 42 | * Unnecessarily long locked resources. | ||
| 43 | * Order can not always be specified. |