Daily life example: you walk down the street, another pedestrian coming in the other direction => you go right, the other pedestrian goes right => you go left, the other pedestrian goes left, etc.
panda
In this example, this livelock is caused from all the cars backing up to make space for potential progress again, but then all moving forward together and causing the deadlock yet again, then backing up again to make space, then moving forward again. This endless loop is creating many operations, yet no progress is being made.
apadwekar
Livelock can sometimes be fixed with randomization. In the case where you are walking down the street and run into a person, if you both try random strategies eventually you might be able to pass. Livelock is much more likely to be maintained if both parties have the same fixed strategy (in the car case if all back away from the intersection).
ask
Another potential solution to avoid livelock is to use some form exponential backoff before trying to access the resource again.
paracon
Is there anyway to detect livelock?
maddy
Is it possible to list specific conditions for Livelock like we did for deadlock?
Levy
The Wifi retransmission mechanism is an example of using random delay interval to avoid livelock. But this one sacrifice efficiency
@paracon, one way I can think of that would be able to detect livelock would just be to run gdb and look at the sequence of instructions run. If we see the same thread repeating a sequence of operations over and over again(when not part of a loop) this would indicate livelock. Kind of like searching for cycles in a linked list
fxffx
A live lock is different from a dead lock in that, in a dead lock, everyone is simply waiting and no one is doing anything; in a live lock, at least some one is doing something, but the whole system is not making program.
Daily life example: you walk down the street, another pedestrian coming in the other direction => you go right, the other pedestrian goes right => you go left, the other pedestrian goes left, etc.
In this example, this livelock is caused from all the cars backing up to make space for potential progress again, but then all moving forward together and causing the deadlock yet again, then backing up again to make space, then moving forward again. This endless loop is creating many operations, yet no progress is being made.
Livelock can sometimes be fixed with randomization. In the case where you are walking down the street and run into a person, if you both try random strategies eventually you might be able to pass. Livelock is much more likely to be maintained if both parties have the same fixed strategy (in the car case if all back away from the intersection).
Another potential solution to avoid livelock is to use some form exponential backoff before trying to access the resource again.
Is there anyway to detect livelock?
Is it possible to list specific conditions for Livelock like we did for deadlock?
The Wifi retransmission mechanism is an example of using random delay interval to avoid livelock. But this one sacrifice efficiency
Examples for solutions of livelock in CSMA/CA and CSMA/CD network -> https://en.wikipedia.org/wiki/Exponential_backoff
@paracon, one way I can think of that would be able to detect livelock would just be to run gdb and look at the sequence of instructions run. If we see the same thread repeating a sequence of operations over and over again(when not part of a loop) this would indicate livelock. Kind of like searching for cycles in a linked list
A live lock is different from a dead lock in that, in a dead lock, everyone is simply waiting and no one is doing anything; in a live lock, at least some one is doing something, but the whole system is not making program.