Re:Common Pitfalls in Writing Lock-Free Algorithms
by starmole on Thursday March 28, 2013 @06:15AM
(#5454034)
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.
[ Parent
| on HN ]
Re:Common Pitfalls in Writing Lock-Free Algorithms
by edsrzf on Thursday March 28, 2013 @06:59AM
(#5454141)
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...
Re:Common Pitfalls in Writing Lock-Free Algorithms
by dannywoodz on Thursday March 28, 2013 @11:52AM
(#5455535)
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?