[zeromq-dev] Improving latency using futexes?
sustrik at 250bpm.com
Tue Nov 24 20:42:46 CET 2009
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
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.
More information about the zeromq-dev