lock-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).
Re:Why Concurrency Is Hard
by RcouF1uZ4gsC on Tuesday November 10, 2020 @12:21PM
(#25048410)
> 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-fr...
thanks 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.
Re:Why Concurrency Is Hard
by CyberDildonics on Wednesday November 11, 2020 @08:44AM
(#25058319)
Lock 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.
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.