[zeromq-dev] Improving latency using futexes?

[Martin Sustrik]

Steven McCoy wrote:
> 2009/11/24 Martin Sustrik <sustrik at 250bpm.com <mailto:sustrik at 250bpm.com>>
> 
>     My assumption was that by using futex directly we avoid an atomic
>     operation that glibc mutex performs in user space before passing
>     control to the kernel.
> 
> 
> The entire point of the atomic operations in user space is to avoid 
> going to the kernel, swapping context to the kernel is expensive.  In 
> the best case scenario - i.e. no lock, no swap to the kernel occurs, 
> when there is a lock the futex call is invoked to govern the locking 
> process.

Right. So when you call pthread_mutex_lock, glibc does an atomic op and 
if it turns out it has to wait it swaps to the kernel mode.

As 0MQ is doing almost exactly the same thing: do an atomic op and if 
waiting is required, it calls pthread_mutex_lock.

Thus, AFAIU one atomic op is done on 0MQ level, other one on glibc level.

What I've tried to do was this: do an atomic op and if waiting is 
required, do syscall (futex, wait) ... I should save one atomic op that way.

Still, the algorithm doesn't seem to be any faster.

Martin