4 ms·
>Oddly, I now find it easier to reason about lock free algorithms than mutex based code That is because lock free code composes. Mutex based code does not comp
by RcouF1uZ4gsC 6y ago
>Oddly, I now find it easier to reason about lock free algorithms than mutex based code
That is because lock free code composes. Mutex based code does not compose. With lock free code, I can freely call another function, knowing I cannot deadlock. With mutex based code, I have to be really careful about the state of my mutexes and think if the code I am calling will attempt to lock one of the mutexes I am holding, thereby causing a deadlock.
- jbn 6y agolock-free code is free of deadlocks, but it is not free of livelocks and usually there's no guarantee of progress... In mutex-based code, usually you want only open calls (i.e. calls with no mutex held, so you only ever hold one mutex at a time).
- RcouF1uZ4gsC 6y ago> usually there's no guarantee of progress I think lock free guarantees that at least 1 thread will make progress. https://en.wikipedia.org/wiki/Non-blocking_algorithm#Lock-freedom https://en.wikipedia.org/wiki/Non-blocking_algorithm#Lock-fr...
- jbn 6y agothanks for the correction. I thought even with that guarantee, there is no bound on progress (so progress can in fact be very slow). lock-free algorithms are not used much because of the slowness, AFAIK.
- CyberDildonics 6y agoLock free means that at least one thread is guaranteed to make progress. You might be confusing this with atomics, which could still be used in a spinlock and would then not be lock free.