Deadlock-
A deadlock is a situation in which two or more competing actions are each waiting for the other to finish, and thus neither ever does.
For deadlock to happen all these four conditions must hold simultaneously
Mutual exclusion
Hold and wait
No preemption
Circular wait
we apply deadlock detection algorithm to check whether the system is in deadlock or not. But if any of the above criterion fails(For example No preemption fails, so some resource is being released) which incur the system to be deadlock free. So what I think, if the deadlock detection algorithm finds the state to be unsafe and all the above four criterion holds true simultaneously then we can say the system is in deadlock.
Unsafe state may or may not lead to deadlock.
But unsafe state with all these 4 conditions holding simultaneously must incur deadlock.
Am I thinking right?
I have another question in my mind. How can we say deadlock has occurred definitely because the next moment some process may release their resources to get rid of deadlock.
Am I thinking right?
Yes, you are correct.
See this link to see why unsafe may not lead to deadlock.
I have another question in my mind. How can we say deadlock has occurred definitely because the next moment some process may release their resources to get rid of deadlock.
Say deadlock has occurred. All processes causing the deadlock are waiting for some resource to be acquired. And because of "No preemption" no such process will get preempted and therefore release resources. Also because of "Hold and wait" property, process needs some more resources to continue but is not going to give up or release whatever it is holding now and will wait till its required resources are met. Once there is deadlock, nothing can happen (there cannot be any progress) until you break one of the above condition. Breaking a condition will make some other process to meet its requirements and ensure progress and completion.
Related
In a given set of processes if some of them can be executed and rest can't because of resources they are requesting for are being held by some other processes. Do we call such a situation as deadlock?
A deadlock situation occurs when none of the process's requests is fulfilled. Each process will be in circular wait, waiting for resources held by other processes.
Necessary Condition for deadlock is
Mutual exclusion
Hold and wait
No pre-emption
Circular wait
Here in this situation, some processes can execute and rest are not able to, so the processes that are not allocated resources will surely be in circular wait.
Hence so this situation can't be called clearly a deadlock situation.
You can go thorugh Operating systems text book by ABRAHAM SILBERSCHATZ (Wiley) 'The Dinasour Book'.
According to Operating System Concepts book, Resource-Allocation-Graph Algorithm can prevent deadlocks as follow:
If we have the following allocation graph
https://www.cs.uic.edu/~jbell/CourseNotes/OperatingSystems/images/Chapter7/7_07_DeadlockAvoidance.jpg
And P1 tried to allocate resource R2, the system prevents it and makes it wait, because that will lead to an unsafe state.
My question is as shown from the graph, P2 is waiting for P1 to release R1, and P1 is now waiting to allocate R2 and that leads to a deadlock. How this algorithm can prevent this type of deadlocks ?
I don't have a copy of your book, but I suspect a typo. The idea is to return an error (EDEADLOCK) to the resource allocation request that would complete the cycle; thus detecting pending deadlock rather than actively avoiding it. It is still up to the process with the failed request to take some corrective action, like dropping all its resources and trying to re-acquire them.
If you replace resources with semaphore or mutex, it should be clear that waiting isn't going to help anything.
To actively avoid deadlock, you pretty much need to either use semaphore sets -- that is acquire all the locks that a particular code path will need in one place (see system V semaphores) -- or arrange your code to use a particular ordering of locks. An example of the latter is to allocate locks by increasing address, thus all actors will attempt the allocation in the same order. Neither is practical for finely grained general purpose code, but possible for transaction processing applications.
Is it guaranteed that by using FCFS scheduling, the 'system' will not be in deadlock?
Thanks in advance!
The four conditions for a deadlock are:
Mutual exclusion: Irrespective of the scheduling algorithm, resources can be possessed by one process without sharing.
Hold and wait: In this condition, processes can wait for other resources while holding onto one resource. This is possible with any scheduling algorithm.
No preemption: FCFS is non-preemptive. That is, processes executing a critical section of their code cannot be forced to stop.
Circular wait: Processes are waiting for another process to release a resource in a circular fashion. This, again, is irrespective of the scheduling algorithm
Hence, FCFS does not guarantee that the system will not be in deadlock. If the four conditions are met, a deadlock will occur.
Deadlocks are caused by resource locking, not scheduling order. FCFS doesn’t guarantee that your threads will always grab resources in sequence, so the answer to your question is no.
In PostgreSQL (and other MVCC databases), transactions can rollback due to a deadlock or serialization error. Assume two transactions are currently running, is it ever possible that both, instead of just one, transaction will fail due to this kind of errors?
The reason why I am asking is that I am writing a retry implementation. If both transactions can fail, we might end up in a never-ending loop of retries if both retry immediately. If only one transaction can fail, I don't see any harm in retrying as soon as possible.
Yes. A deadlock can involve more than two transactions. In this case more than one may be terminated. But this is an extremely rare condition. Normally.
If just two transactions deadlock, one survives. The manual:
PostgreSQL automatically detects deadlock situations and resolves them by aborting one of the transactions involved, allowing the other(s) to complete.
Serialization failures only happen in REPEATABLE READ or SERIALIZABLE transaction isolation. I wouldn't know of any particular limit to how many serialization failures can happen concurrently. But I also never heard of any necessity to delay retrying.
I would retry as soon as possible either way.
I have four questions regarding the relation between starvation and bounded waiting.
Does starvation-freedom imply deadlock-freedom?
My answer:
From here, the definition of starvation free is
Freedom from Starvation -:Every thread that attempts to acquire the lock eventually succeeds
Freedom from Deadlock -:f some thread attempts to acquire the lock, then some thread (not necessarily the thread referred to in the if statement; emphasis added) will succeed in acquiring the lock.
So I can state that starvation-freedom imply deadlock-freedom
Does starvation-freedom imply bounded-waiting?
Does bounded-waiting imply starvation-freedom?
Does bounded-waiting AND deadlock-freedom imply starvation-freedom?
I am stuck at point 2,3,4.
2.Does starvation-freedom imply bounded-waiting?
Starvation means that a thread will wait indefinitely. But starvation-freedom means the thread will not wait forever and will eventually get the resource. Bounded waiting means there is a limit to the number of times the threads are allowed to enter their critical sections after a thread has made request to enter its critical section and before that request is granted. So, its clear that starvation freedom implies bounded waiting, otherwise, some other thread can always be in Critical section and that contradicts starvation-freedom.
3.Does bounded-waiting imply starvation-freedom?
The answer is also yes because after the limit is crossed the waiting process will get the chance to enter critical section and therefore, no indefinitely waiting and therefore, starvation-freedom.
4.Does bounded-waiting AND deadlock-freedom imply starvation-freedom?
It is clear from the above explanation that it is also true.