algo::Unpack: Unpack BMON and MUCH in parallel.

Unpack BMON and MUCH in parallel. Additionally protect against invalid ids during parallel unpacking.

@d.smith, could you have a look? Changes are in similar fashion to what was already with STS and TOF.

requested review from @d.smith

added 5 commits

• b4ed6340 - Unpack: Make BMON Unpacker thread-safe.
• 050ff780 - Unpack: Unpack BMON in parallel.
• a8f7d7ad - algo: Make MUCH Unpacker thread-safe.
• 284f07de - algo::Unpack: Unpack MUCH in parallel.
• b25a81d5 - algo::Unpack: Add protection against invalid equipment ids and system versions...

Compare with previous version

In principle similar changes could done to the RICH unpacker as well (and should be because it's more expensive than BMON and MUCH). But the UnpackRich class contains a lot more fields and from reading the code it's not clear to me that all of these are reset with each MS. Which would be required to unpack in parallel. @d.smith, do you happen to know more here?

Dear @f.uhlig, @v.friese, @p.-a.loizeau,

you have been identified as code owner of at least one file which was changed with this merge request.

Please check the changes and approve them or request changes.

added CodeOwners label

The changes look fine to me. I assume it was verified that the output doesn't change.

It is less obvious for RICH due to the rather large tower of nested function calls, but all microslices are indeed independent, so all of the fields are reset. So in principle everything could be packed into a struct which is created at the top-level function call and then passed by reference as an argument, as is done here.

Due to the fact that the digis are created at the innermost layer of functions, I introduced a digi vector as a class field for RICH, which is cleared for each MS. This could in principle also be achieved through a local object instance which is passed down, at the expense of having longer argument lists. This probably a necessity for parallelization.

The only unpacker for which microslices are currently not independent is TRD2D, which has an additional FinalizeComponent() function which is called for each component after the MS loop. I think @a.bercuci mentioned that this would be dropped / fixed at some point. My current approach was to simply call this function for each MS instead. This leads to a very small number of lost digis.

Basically, TRD2D in general uses multiple hit messages for a single digi, and in rare cases they can spill over between microslices. The FinalizeComponent() function cleans up any remaining messages that are still in the buffers at the end of the component and turns them into digis.

approved this merge request

merged

Thanks for clarifying! I'll open a seperate MR to adapt the RICH unpacker.