libbabeltrace2: question about thread safety

[Simon Marchi]

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