Skip to content

CaloTopoClusterTowerMerger try to reduce the number of locks

CaloTopoClusterTowerMerger try to reduce the number of locks

This is motivated by this being number 5 in the list at slide 4 here : https://indico.cern.ch/event/1112060/contributions/4679795/attachments/2370972/4049482/AthenaLocks20220111.pdf

I am not convinced that this is a contested case. But is an easy fix and perhaps no locks will be better / faster ... Still , I would not suggest to go to wild.

The graphs :

Before this change we have 400 k calls to mutex lock

Locks_before pthread_mutex_lock_before

After this change we have 50 K calls to mutex lock

Locks_after pthread_mutex_lock_after

Notes

The 350 k removed are just because we were doing new via the the copy ctor and then we were passing to the container (push_back). This goes through private store. We can new via the default ctor, pass to the container and then assign and avoid that.

The remaining ones are about "resize"/"setLink" and Aux items.

As said do not think that these are contested and the root of current scaling issues , is one to take a lock "in case" for correctness reasons and a bit another for the lock to be heavily contested.

Let me cc @amete , @akraszna , @goetz , @ssnyder , @tadej which were on the thread relevant to the presentation above.

Edited by Christos Anastopoulos

Merge request reports