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

[Stephen Hemminger]

On Fri, 6 Sep 2019 16:04:33 +0100

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

[1] is about sd-bus, not sd-event, and doesn't say anything about whether
sd-event is designed to be thread-safe or not.
However, I think you're correct to say that struct sd_event is also only
designed to be used from the single thread that "owns" it.
If you need a thread-safe event loop, then you need something like
GLib's GMainContext, with mutexes to protect its data structures against
concurrent access, and a well-defined mechanism for one main-context to
"post" events to other main-contexts (which might be running concurrently
in a different thread). Many other event loops are available; GMainContext
happens to be the one I'm most familiar with, and I know that it is
designed to be thread-safe.
The price that things like GMainContext pay for being thread-safe is
that they are more complex and less efficient than sd-event: in general,
all operations on a thread-aware event loop have to pay the complexity
and performance cost of being thread-aware, even if the current program
only has one thread.
smcv

Excuse me for reviving an old thread. But I see similar problem today
(especially on Arm). The sd-event model uses signals so it is inherently
subject to thread issues.

It looks like a stronger memory model is needed here (not volatile).
Other projects use __atomic builtins for this.

[Lennart Poettering]

Post by Stephen Hemminger
On Fri, 6 Sep 2019 16:04:33 +0100

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

[1] is about sd-bus, not sd-event, and doesn't say anything about whether
sd-event is designed to be thread-safe or not.
However, I think you're correct to say that struct sd_event is also only
designed to be used from the single thread that "owns" it.
If you need a thread-safe event loop, then you need something like
GLib's GMainContext, with mutexes to protect its data structures against
concurrent access, and a well-defined mechanism for one main-context to
"post" events to other main-contexts (which might be running concurrently
in a different thread). Many other event loops are available; GMainContext
happens to be the one I'm most familiar with, and I know that it is
designed to be thread-safe.
The price that things like GMainContext pay for being thread-safe is
that they are more complex and less efficient than sd-event: in general,
all operations on a thread-aware event loop have to pay the complexity
and performance cost of being thread-aware, even if the current program
only has one thread.
smcv

Excuse me for reviving an old thread. But I see similar problem today
(especially on Arm). The sd-event model uses signals so it is inherently
subject to thread issues.

Hmm? sd-event uses signals only via signalfd(), so that it can
dispatch them as part of regular event loop handling. It doesn't
install a signal handler or anything like that.

Post by Stephen Hemminger
It looks like a stronger memory model is needed here (not volatile).
Other projects use __atomic builtins for this.

All of sd-event's data structures should be accessed from a single
thread only, in a single non-signal execution context.

Lennart

--
Lennart Poettering, Berlin