"....and is restarted with the same timestamp if killed." This statement needs all of your attention.
Ph: Process that is Holding.
Pr: Process that is Requesting.
if T(Pr) < T(Ph) then
kill Pr
else wait
If a process is respawning again with same timestamp then why to kill?
Well, it has its own perks. (it avoids Deadlock, explained later in this answer.)
If any process is holding some resource, Does it give it to anyone?
Nopes. No one can take it (Unless holding process completes execution), Either Requesting process will be killed or Requesting process will wait.
Now see this scenario: (P3 holds R, all other requesting it.)
In this case P2, P4 and Pi all will wait for R. (only difference is, P2 will be killed again and again.)
Once P3 releases R on completion, Who will get R ?
-Any process irrespective of its timestamp can take R. And some arbitrary process Pi may starve.
This Shows that implementation is NOT starvation free.
Will it be deadlock free?
-Yes.
"....and is restarted with the same timestamp if killed." Because of this statement, Hold and wait can never arise. Because when we kill the process, it forces to release all of its currently holding resources.
Think about classical 2 processes, 2 resources deadlock.
The moment P1 requests for R2, it will be killed and R1 will be given to P2.
This avoids Deadlock.
We can think this resource allocation scheme as Deadlock Prevention scheme as it always prevents Circular wait.
If somewhere this exact code is given as an example of Deadlock Prevention scheme, It won't be surprising for me.
Hence A.