As I put in the first sentence, I might be missing a lot there. Could you please point me to the definition you are referring to? I probably did not express myself very well. And I already learned a bit by thinking about this differently. You (and everybody else, so you are right!) define lock free as dead lock free. Which can be done with a carefully chosen lock. I was always thinking of lock free as a pure performance optimization which admittedly is different to the algorithmic property. Am I on the right track? If yes, it should answer your question why I got involved in the discussion: to learn.

Dmitry Vyukov keeps a great resource for learning about lock-free algorithms (and other interesting things) here: http://www.1024cores.net/home/lock-free-algorithms/introduct...

Isn't the very first example in that article flawed?

    void decrement_reference_counter(rc_base* obj)
    {
        if (0 == atomic_decrement(obj->rc))
            delete obj;
    }

This is classic test-then-act, isn't it? What happens if another thread bumps obj->rc after the comparison to 0, but before the deletion? That other thread could find itself referring to a suddenly-deleted object, or am I missing something?

> If you don't know what it is, why get involved in this discussion?

To understand?