3 ms·
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 mys
by starmole 14y ago
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.
- 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?