SiDetElement , try to reduce a bit the locking.

This should go in after !26010 (merged) As it makes semantically sense when updateCache is private.

One can think the "issue" as

• The recursive lock is needed due to one public const method calling another public const method that has part of the implementation it needs.
• Since the method that is called can also be called individually we need a lock.
• And since the other public method needs also a lock , we end up with a recursive lock (that can be taken multiple times from the same thread)

One way to remove the need for a recursive lock is

• To take out the implementation in a private method.
• This implementation does not need a lock.
• Then the relevant methods could call the implementation method under a lock without being afraid that the implementation function will also try to lock

For now I am focusing on the updateCache and the methods called from inside update cache

if this can be done then prb we will be close into not having that strong need for a recursive mutex.

As per usual on this mentioning @oda