libbabeltrace2: question about thread safety

libbabeltrace2: question about thread safety

[MOESSBAUER, Felix via lttng-dev]

Hi,

I just noticed that the reference counting in libbabeltrace2 is not
atomic - and by that not thread safe. As I can't know where reference
counting on global objects (like the plugin or component instances) is
done internally, I'm assuming I can't execute two (independent) graphs
in parallel. Some quick tests with tsan seem to confirm my assumption.

Is there any (documented) way to run two graphs in parallel? Or shall
the whole library just be used behind a global mutex?

Best regards,
Felix

-- 
Siemens AG
Linux Expert Center
Friedrich-Ludwig-Bauer-Str. 3
85748 Garching, Germany

Re: libbabeltrace2: question about thread safety

[Simon Marchi via lttng-dev]

On 10/23/26 4:11 AM, MOESSBAUER, Felix via lttng-dev wrote:
> Hi,
> 
> I just noticed that the reference counting in libbabeltrace2 is not
> atomic - and by that not thread safe. As I can't know where reference
> counting on global objects (like the plugin or component instances) is
> done internally, I'm assuming I can't execute two (independent) graphs
> in parallel. Some quick tests with tsan seem to confirm my assumption.
> 
> Is there any (documented) way to run two graphs in parallel? Or shall
> the whole library just be used behind a global mutex?

(resending from another address to try to avoid the spam filter)

I think the idea was that running two graphs simultaneously in two
threads would not be a problem, because they don't share anything.  But
you are right that plugins and component classes are actually shared.
The action of adding a component to a graph touches the component class'
refcount, and so does destroying the graph (and there is the "freeze"
status too, if the lib is built in dev mode).

I think it would make sense for libbabeltrace2 to have some
synchronization in the plugin / component class area to allow for two
threads to build, run and destroy graphs without requiring any locking
on the user side.  But that won't be trivial, and it's not on the
roadmap as we speak.

In the mean time, you could try having a global lock but only for the
graph building and destruction phases?  Or have a single thread
responsible for building and destroying graphs.  I'd be curious to know
if this is enough or if there are other concurrent accesses we haven't
spotted.

Simon

Re: libbabeltrace2: question about thread safety

[Moessbauer, Felix via lttng-dev]

On Thu, 2026-11-05 at 14:47 -0500, Simon Marchi wrote:
> On 10/23/26 4:11 AM, MOESSBAUER, Felix via lttng-dev wrote:
> > Hi,
> > 
> > I just noticed that the reference counting in libbabeltrace2 is not
> > atomic - and by that not thread safe. As I can't know where reference
> > counting on global objects (like the plugin or component instances) is
> > done internally, I'm assuming I can't execute two (independent) graphs
> > in parallel. Some quick tests with tsan seem to confirm my assumption.
> > 
> > Is there any (documented) way to run two graphs in parallel? Or shall
> > the whole library just be used behind a global mutex?
> 
> I think the idea was that running two graphs simultaneously in two
> threads would not be a problem, because they don't share anything.  But
> you are right that plugins and component classes are actually shared.
> The action of adding a component to a graph touches the component class'
> refcount, and so does destroying the graph (and there is the "freeze"
> status too, if the lib is built in dev mode).

Hi, thanks for the clarification. This behavior should at least be
documented.

> 
> I think it would make sense for libbabeltrace2 to have some
> synchronization in the plugin / component class area to allow for two
> threads to build, run and destroy graphs without requiring any locking
> on the user side.  But that won't be trivial, and it's not on the
> roadmap as we speak.

Without looking into it more deeply, I guess just making the ref
counting atomic would be sufficient. That should be a rather small
change with a minimal performance impact on modern platforms.

> 
> In the mean time, you could try having a global lock but only for the
> graph building and destruction phases?  Or have a single thread
> responsible for building and destroying graphs.  I'd be curious to know
> if this is enough or if there are other concurrent accesses we haven't
> spotted.

As I was unsure what exactly is shared, I just moved the graph
processing to individual processes (the processing is done as part of
an HTTP MCP server, so I expect multiple calls to arrive in parallel).

PS: While this solves the race conditions on the refcounting, it does
not help to speedup the graph processing, as this still happens
sequentially. Ideally that could be parallelized as well, especially as
we know the graph layout upfront.

Felix

> 
> Simon