[zeromq-dev] atomic ops

[john skaller]

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
skaller at users.sourceforge.net