3 ms·
"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 unfo
by johnduui 14y ago
"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?
- bnegreve 14y ago> If you don't know what it is, why get involved in this discussion? To understand?
- starmole 14y agoAs 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.
- edsrzf 14y agoDmitry Vyukov keeps a great resource for learning about lock-free algorithms (and other interesting things) here: http://www.1024cores.net/home/lock-free-algorithms/introduction http://www.1024cores.net/home/lock-free-algorithms/introduct...
- dannywoodz 14y agoIsn'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?