Deadlock occurs while you are getting an additional resource while holding another or more resource, especially when it creates a circularity (Sandén, 2011).
Sandén (2011), stated that to prevent deadlocks, resources need to be controlled. One should do a wait chain diagram to make sure your design can help prevent a deadlock. Especially when there is a mix of transactions occurring. It is also best to know how many threads/entities are needed to be called on simultaneously before a deadlock can occur, especially true when you have multiple threads calling on shared resources.
Thus, we should manage the resources to ensure no circularity, limit the number of entities to just below the threshold to cause a deadlock, eliminate wait.
There are many in real life like the one shown in Sandén (2011) with each of 4 cars halfway into an intersection. The following is a real-life suggested a deadlock scenario:
There is one set of measuring cup (1/2 a cup). There are no other ways to measure this amount. Jack and Jill are backing a cake at the same time. They have all the objects need, eggs, cake mix, oil, and milk. However, they need the only measuring cup to measure oil and milk and they reach for it at the same time. This is a deadlock.
To un-deadlock this scenario, Jack can pour the eggs, and cake mix, while Jill measures and pours the oil and milk. When Jill is done, Jack measures and pours the oil and milk and Jill pours the cake mix and eggs. The same could be done with up to four people. Where each person is a thread and the measuring cup is the resource.
Once we introduce a fifth or more person, the wait chain has unnecessarily long periods of wait for one thread to be able to begin to use a resource.
Reference
- Sandén, B. I. (2011-01-14). Design of Multithreaded Software: The Entity-Life Modeling Approach, 1st Edition. [VitalSource Bookshelf Online]. Retrieved from https://bookshelf.vitalsource.com/#/books/9781119143086/