Hacker News Reader

Comment by johnduui | Hacker News Reader

"to me lock free means an algorithm where both producers and consumers have to only ever access one single atomic value"

Well it may mean that to you, but unfortunately it doesn't mean that to anyone else.

Lock free has a precise definition. If you don't know what it is, why get involved in this discussion?

View on HN

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?

Reply on news.ycombinator.com