I was reading concept of deadlock from Galvin and I am getting a doubt that can a single process / thread ever go in deadlock...? Coz the definition (or as a matter of fact the whole Deadlock chapter in Galvin) doesnt seem to be talking about what if there is a single process / thread in the system.. (Plz tell if I have missed upon any point..while reading it...if yes sincere apology..for my previous statement but I simply could not find it in chapter anywhere..)
Every where Galvin Book uses the word "Other" process while describing deadlock scenario... So what I feel the answer to my question is No , a single process / thread can never go in deadlock.. (Okay also me: what I feel that a single process in some case may lead to indefinite waiting ..can I call it as a deadlock..?)
To know the motivation why I am bringing Deadlock and Indefinite waiting into one Picture..plz read below scenario (Okay also plz let me know that whether I am correct in assuming that indefinite waiting is not same as deadlock...i may be wrong..??) Consider a scenario: There is one thread (t) and one lock(l). Lock nature Non re entrant. (Meaning when thread holds lock l then it cannot acquire it once again before it releases it...I could find only this as definition on internet.) (One more condition: If a thread could not acquire lock then it blocks itself untill it gets available...yes it's pretty obvious point but this point is creating mess..plz read below to get insight..) Now it's claimed that say t acquires a lock l and then does its execution meanwhile it requires the same lock again..(may be because it has to Do some recursive function call...like as in BFS/ DFS...or may be something similar..) So obviously it has to leave that lock before acquiring that lock...but since process cannot acquire same lock again so it has to wait or simply gets blocked till it becomes available... Now the important point is ...it would be blocked till it ..itself releases the lock..now my question is can this scenario lead to a deadlock... (Yes it can release again..and then reacquire...but my problem is not pertaining to this case..) So my problem is can this case ever lead to deadlock...(like thread waits for itself...) -->like in worst case type scenario.. (Also whenever a process / thread goes in blocking state /waiting state does it hold locks/ resources..??plz also shed light here ...) (I hope what I am talking about is clear...if not plz comment and tell I'll try my best to clarify...yes this point is very delicate where I want to raise doubt)
That scenario is actually an exam problem..whose answer is : Yes a single thread with single lock can lead to deadlock-->which I feel conflicts with deadlock defintion..) I know I am raising many doubts but the primary problem is same.
Below is key point summary of my doubt:
-single process/ there's in deadlock?
-indefinite wait vs deadlock
-is it necessary for a process/thread to release locks..when goes in blocked/waiting state?
(First of all thanks if you made it till this point...coz it's really a long doubt..I did it just so as to make my point clear...if not comment..I'll make it again..)
single process/ there's in deadlock?
Yes, as you mentioned, if a function in the thread holds a lock and recursively calls itself, then it could lead to a deadlock. If the lock has been implemented to not block, when the already holding thread requests for the lock, then, of course, we won't have the deadlock.
indefinite wait vs deadlock
No these are not one and the same. A deadlock happens if none of the threads are able to make progress. If one thread (holding the lock) is able to make progress while blocking/delaying other threads indefinitely, that's not a deadlock. Another interesting concept is Livelocks - where threads are not making progress but appear to be "alive"/active.
is it necessary for a process/thread to release locks..when goes in blocked/waiting state?
No, for example, suppose a thread holds a lock to protect a memory page from being accessed by other threads, and then starts a read from disk into that memory page. This I/O is would most likely suspend the thread, until the transfer from disk completes. This is a legitimate use of hold-the-lock-and-suspend. There are numerous such cases, where threads can block while holding the lock.