> If you actually care about real-time guarantees enough to look into lock-free solutions, lock free does not give any real time guarantee for any specific tas

> If you actually care about real-time guarantees enough to look into lock-free solutions, lock free does not give any real time guarantee for any specific task (and neither does wait free, a much stronger and harder to achieve constraint) The reason I use it when I do, is that it guarantees that a problem in one thread/worker/process, e.g. a stall due to a database commit, does not make others stall as well. > (CAS to acquire a work item) Most likely, you've just described a lock free implementation. > I assume I'm missing something, since I'm somewhat new at this, and lock-freedom is clearly in vogue, but I don't know what it is. Lock freedom is the property that, at any instant, at least one thread/worker/process is making some progress independently of the others. It is a useful definitions because it doesn't care whether locks are explicit (e.g. mutex, semaphore, critical section) or implicit (polling or spinning or whatever)