(Disclaimer: posted mid-lecture so haven't really seen ) In the real world, this problem is resolved by having all the cars behind the bus back up so that the bus can back up too and the car can move forward, or by having the car back up until the bus has room to move forward. Can this principle be applied to resolving deadlock as well?
rohany
Ideally we could, but in alot of cases, protocol for going back one step in a dependency chain is either hard to do, or hard to implement i think (from personal experience).
kayvonf
@myeditha. One small nit. You mean avoiding deadlock, not resolving it! To reach a state of deadlock we must have a situation where a resource is acquired and held by an actor while that actor is waiting for something else to happen (another resource to come free). This is the "hold and wait" condition on slide 13.
paracon
@myeditha I would consider using rollback after deadlock detection is similar to your method of resolving the yinzer deadlock.
viveksri
I'm not sure how actually relevant this is, but your comment reminded me of it @myeditha . I know there are some debuggers that actually let you step backwards in time in program execution (e.g. Green Hills Software iirc), and this would theoretically allow you to "resolve" a deadlock; however, I don't think it's possible or feasible to do this in a non-debug environment in real time.
(Disclaimer: posted mid-lecture so haven't really seen ) In the real world, this problem is resolved by having all the cars behind the bus back up so that the bus can back up too and the car can move forward, or by having the car back up until the bus has room to move forward. Can this principle be applied to resolving deadlock as well?
Ideally we could, but in alot of cases, protocol for going back one step in a dependency chain is either hard to do, or hard to implement i think (from personal experience).
@myeditha. One small nit. You mean avoiding deadlock, not resolving it! To reach a state of deadlock we must have a situation where a resource is acquired and held by an actor while that actor is waiting for something else to happen (another resource to come free). This is the "hold and wait" condition on slide 13.
@myeditha I would consider using rollback after deadlock detection is similar to your method of resolving the yinzer deadlock.
I'm not sure how actually relevant this is, but your comment reminded me of it @myeditha . I know there are some debuggers that actually let you step backwards in time in program execution (e.g. Green Hills Software iirc), and this would theoretically allow you to "resolve" a deadlock; however, I don't think it's possible or feasible to do this in a non-debug environment in real time.