[systemd-devel] EXT: sdbus_event loop state mark as volatile?

Ray, Ian (GE Healthcare) ian.ray at ge.com
Fri Sep 6 06:57:22 UTC 2019



> On 5 Sep 2019, at 20.46, Stephen Hemminger <stephen at networkplumber.org> wrote:
> 
> The libsystemd bus event loop is:
> 
> 
>        while (e->state != SD_EVENT_FINISHED) {
>                r = sd_event_run(e, (uint64_t) -1);
> 
> But since e->state is changed by another thread it

What other thread?


> should be marked volatile to avoid compiler thinking
> the state doesn't get changed.
> 

The “volatile” keyword does not equate to thread safety.

If thread-safety is a design goal (and I don’t believe that it is [1])
then atomic or thread-safe primitives should be used.

[1] https://lists.freedesktop.org/archives/systemd-devel/2017-March/038519.html


While “volatile” _is_ a useful hint to the compiler, it provides *no*
atomic or thread-safe guarantees: for example about the ordering and
visibility of operations in a multi-core system.

It is true that for _certain_ { chipset, compiler, compiler-option }
combinations we can effectively reason about atomicity [for example
of word-size integers], however this does not generalise, and is
certainly not portable.

Ian


> 
> diff --git a/src/libsystemd/sd-event/sd-event.c b/src/libsystemd/sd-event/sd-event.c
> index 5adbceeb0247..b7be2472a398 100644
> --- a/src/libsystemd/sd-event/sd-event.c
> +++ b/src/libsystemd/sd-event/sd-event.c
> @@ -90,7 +90,7 @@ struct sd_event {
> 
>         uint64_t iteration;
>         triple_timestamp timestamp;
> -        int state;
> +        volatile int state;
> 
>         bool exit_requested:1;
>         bool need_process_child:1;
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel



More information about the systemd-devel mailing list