libev, multiple threads, and ev_async as notification vs valgrind/helgrind

Marc Lehmann schmorp at
Fri May 2 16:36:50 CEST 2014

On Fri, May 02, 2014 at 04:12:29PM +0200, Christian Parpart <trapni at> wrote:
> I hope somebody can tell me that this is a false positive or what I might
> be missing.

Most likely, these are either bugs in helgrind (not emulating the memory
fence instruction correctly) or simply a design limitation in helgrind, in
that it doesn't support lockfree data structures, or maybe it has a
concept of data race that cannot distinguish between problematic data races
and harmless ones (ones that don't break the few guarantees that libev

Unfortunately, I am not up to the task of analysing helgrind and its
limitations, so maybe you need to ask somebody who knows (about valgrind).

I'm pretty confident that there are no races at the hardware level in

> >From what I can think of, I should not need any locks at for my threading
> model, there watchers are only modified inside their respective worker
> threads *except* the fact, that ev_async is used to notify thread A to
> thread B to wake up and do some work.

Yes, thats correct (and libev itself also doesn't use/need any locks).

> As you may see in the backtrace, I also tried to add a lock around struct
> ev_loop uses, as shown in the example of the libev man page, in the hope,
> that maybe I need that part there anyways, but appearently that didn't fix
> it either.

It's also not needed - indeed ev_async should be safe to call from another
thread without locking, and if otherwise you do everything in the same
thread, you also don't need any locking.

                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_    
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at
      -=====/_/_//_/\_,_/ /_/\_\

More information about the libev mailing list