Make cache thread-safe

[auguste-probabl]

Is your feature request related to a problem? Please describe.

We are currently delegating adding keys to the cache to the callers:

https://github.com/probabl-ai/skore/blob/9bae5d2ee9ce212add2fb6b35514e5020148912a/skore/src/skore/_sklearn/_base.py#L337-L341

This makes skore code more complex as callers have to know about this peculiarity of the cache.

Describe the solution you'd like

The current code is a quick fix to preserve thread-safety. We should rework the caching mechanism to make it thread-safe, and move back all the adding keys logic into the cache module.

Describe alternatives you've considered, if relevant

No response

Additional context

No response

[thomass-dev]

Before reworking the caching mechanism, we could simply share an explicit lock wherever the cache is managed.

Funny fact: i asked @glemaitre this morning if it will be a problem to compute metrics in parallel (in #2114), and he answered me "the cache could be an issue".

Can we prioritize a quick fix with what i proposed if you are agree?

[glemaitre]

@thomass-dev for your case, would it be enough to trigger the collection of the prediction using the cache_predictions and then parallelize the rest that should mainly read or write with different key in the dictionary?

[glemaitre]

Oh I'm reading your message about the lock. Until that the lock is for writing in the dict then it would be fine. I think that accessing in "read-only" mode should not be locked.

[glemaitre]

Let's add this issue to the meta issue about the cache for when we will redesign. In the meanwhile, let's find a workaround that works for @thomass-dev

[thomass-dev]

Until that the lock is for writing in the dict then it would be fine. I think that accessing in "read-only" mode should not be locked.

Yes, i also think that locking operations that can change the state of the dictionary is sufficient.
IMO, the worst case in reading is: i try to access a resource using the cache-key x that is unavailable, so i compute it. In the meantime it is finally available. I will overwrite the value. I may have done the work twice.

I'm starting an implementation.

[auguste-probabl]

I'd like to test whether this impacts performance on something like a big ComparisonReport of many CrossValidationReports.