> On 5 Sep 2019, at 20.46, Stephen Hemminger <stephen@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/systemd-devel _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel