News for hackers. Stuff that matters.

A comment on Why Concurrency Is Hard. Parent comment

Re:Why Concurrency Is Hard by jbn on Tuesday November 10, 2020 @09:43AM (#25046474)
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).

[ Parent | on HN ]
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...

[ Parent | on HN ]
Re:Why Concurrency Is Hard by jbn on Wednesday November 11, 2020 @10:05AM (#25058947)
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.
[ Parent | on HN ]
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.
[ Parent | on HN ]