On 09/02/2012, at 12:53 PM, Luca Fascione wrote: > I agree with everything else you said, > but I'm not sure I understand why this is lock free... (I see it has no > mutex locks, indeed...)
Well if there's no locks its lock free :) At the core most locks use spin-locks, spin locks, obviously, are CPU intensive if they don't sleep a bit, and create a latency issue if they do. Users don't normally do low level locking, its done by the OS, which means an expensive context switch. So lock free is supposed to be cool. Lock free only works in particular algorithms. Thread safe lock free data structures/algorithms are supposedly good because they're fast and don't waste resources. > Couldn't you have an infinite pingpong of a couple threads starving each > other, because they never manage to agree on what the refcount should be? > (as in they cause each other's check of the ref count to fail forever) In theory, generally yes. In practice, this is rare. The theory can be modified to ensure it doesn't happen by making an assumption called "progress". Roughly that means that, however slowly, all threads will actually execute a bit, so eventually the algorithm will succeed. Hard real time operating systems do not provide progress across priority boundaries: high priority threads always execute to the exclusion of lower priority ones. Most OS, however, try to exercise all the threads a bit: high priority threads get more CPU but never all of it. This is particularly important squashing certain kinds of DNS attacks that hit higher priority layers, but need to be manager from a lower priority (application) level: if you want to shut down your network interface card because it's being spammed, you need enough cycles to type the command on the console :) BTW: I'm not saying 0MQ implementation is bugged, just explaining why I'm suspicious :) -- john skaller [email protected] _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
