Streamers for std::atomic

Dear Root-Devs,

I’ve just a quick feature request: It would be great if you could include streamers for std::atomic to increase the support of multi-threading applications.

Currently I created my own template TAtomic class which just derives from TObject and std::atomic and adds a simple (non-atomic) streamer. Its ok, but this kind of wrapping appears kind of “unelegant” to me :wink:

Cheers,
Jochen
TAtomic.h (583 Bytes)
TAtomic.cpp (1.24 KB)

Hi Jochen,

thanks for the code: it looks interesting, but as you say, it could be a bit heavy, especially when thinking about fitting the data in a cacheline.
Presently, of the new stl library, shared_ptr, unique_ptr, array, and atomics are the most notable entities which cannot be streamed. The first three are in our plan of work.
What is your use case for a persistent atomic?

Cheers,
Danilo

Hi Danilo,

re “shared_ptr, unique_ptr, array” <- Yay! Looking forward to these. Refrained from using them exactly bc no streamers were available.

My usecase for the above and the atomics is the simulation system I’m currently writing. I want to be able to store the whole state of the simulation at a single point in time with ideally just writing one instance of a “root”-class which represents the simulation state. This class, among other things, hands out unique IDs to the entities in the simulation. As the simulation is processed by multiple threads the access to this “nextFreeID” must be secured. However, if i store the simulation state, i want to store the nextFreeID as well.

In general, storing and loading complex data structures more or less automatically is really one of the greatest features of ROOT to me. :slight_smile:

Cheers,
Jochen

Hi Jochen,

while there is some thinking/whiteboard/coffee to go before implementing the solution for transparently stream std::atomic types, for your particular case you could decide to adopt a solution like the following.
You could have:
o A transient, thread safe cache of type std::atomic which is used to store the IDs coming from the different threads.
o A persistent member holding the ID
o A method to checkpoint the state of the class instance before writing which will transfer the content to the transient to the persistent member
o A method that restores the value of the persistent member in the transient cache (not sure if this is needed in your setup)

Danilo