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'.
Related
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.
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.
I know deadlock and starvation definitions, but I'm still confused in these few points (Unable to arrive at which one is correct)
a) deadlock is a extreme case of starvation
b) deadlock and starvation are two unrelated concepts
c) starvation only leads to deadlock
Deadlock: is when all the processes do not get access to resources because every process is waiting for some another process and there is a cycle.
Starvation: is when a low priority process does not get access to the resources it needs because there is a high priority process accessing the resources. The entire system of processes hasn't come to halt in this case.
Since, only low priority process does not have access to resources in starvation, while in deadlock no process has access to the resources they need therefore deadlock is an extreme case of starvation with the criterion of extremeness being the total count of process unable to access the resource.
Deadlock and starvation are related as both are the cases of a process not having access to the resource.
Starvation does not lead to deadlock as a starving low priority process keeps waiting while other processes with high priority run to completion.
Rumor has it that when they shut down the IBM 7094 at MIT in 1973, they found a low-priority process that had been submitted in 1967 and had not yet been run.‡
‡Mentioned in the Operating System Concepts book by Abraham Silberschatz, Peter B. Galvin, Greg Gagne
Well, a is correct.
Starvation can lead to softlock or suboptimal performance (scheduling).
Since deadlock is a special case of starvation (all contenders are resource-starved) they are /not/ unrelated.
DeadLock : If two threads are waiting for each other and forever,such type of infinite waiting is called deadlock.Long waiting of a thread where waiting never ends is also called as deadlock.
Starvation : Long waiting of a thread where waiting ends at a certain point is called as deadlock.
For example low priority thread has to wait until completing all high priority threads,it may be long waiting but ends at certain point,is nothing but starvation.
Assume we are using semaphores for providing mutual exclusion and one process is executing in critical section. Then another process comes to use the critical region, would it be put into the waiting queue?
I have a doubt that which process puts this process in the waiting queue?
Thanks in advance,
In a typical operating system this is handled by the kernel and not a process. The kernel keeps track of what critical regions exist and which processes are occupying them. Also in a typical operating system the scheduler is also part of the kernel so it is the scheduler that will put the process in a waiting state (or to be more precise more likely a blocking state).
When a thread/process/task requests a mutual exclusion object, it makes a system call to the kernel where mutual exclusion objects are handled. If this object is not available at the moment, then the kernel puts this thread/process/task in the waiting/blocked queue and elects another one.