[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