[libev] Is ev_async_send() a seq. cst. barrier?

Marc Lehmann schmorp at schmorp.de
Tue Apr 7 02:50:46 CEST 2015


On Mon, Apr 06, 2015 at 01:42:01PM -0700, Andrey Pokrovskiy <wonder.mice at gmail.com> wrote:
> Is it a correct assumption that ev_async_send() is a sequential
> consistency barrier?

No - while it probably acts like one in most cases, it isn't officially
one, so the assumption would be wrong.

> Where "sent" is a volatile sig_atomic_t which doesn't impose any
> ordering (afaik).

Since ordering is highly dependent on your implementation, a volatile
sig_atomic_t might or might not impose any ordering. But C, in general,
doesn't have a way to impose ordering - you'd have to rely on C11 or some
other implementation specific feature.

> Consider:
>     (1) last_event = event; // or __atomic_store_n(&last_event, event,
> __ATOMIC_RELEASE);
>     (2) ev_async_send(ev_event);
> I think it's possible that "w->sent = 1" in (2) can be moved (observed
> by other threads) before (1).

It might well be - ev_async_send makes no guarantees about anything
outside of libev, it merely delivers the event to the callback.

Note that this last example doesn't really have a connection with
ev_async_send being a seq cst barrier - ev_async_send usually acts
like one, as a whole, while the operations it consists of do not (i.e.
ev_async_send has other side effects apart from acting like a barrier).

At this point in time, however, you need to assume that ev_async_send
doesn't have any barrier qualities you can rely on. Depending on compile
time configuration, e.g. -DECB_NO_SMP, ev_async_send is guaranteed not to
have any barrier effect at this time, so this assumption is true both in
theory and practise.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\



More information about the libev mailing list