multithreading issue about caches HOT 3 CLOSED

Hello @laurentcau,

What you describes relates to "transaction" thread-safety rather than object thread-safety. Indeed, a reference/pointer returned by Get/TryGet methods may be invalidated by calls to Put/Remove. But it is up to a caller to provide a safety of a cache container in a multithreading environment. Or a method might be introduced that would return a shared pointer to a data to avoid early resource invalidation.

I would be more than happy to merge such a change if you see a value for doing so. 😄

from caches.

from caches.

Missed a response there. 🤦

If you have to manage thread-safety on caller side, this mutex is useless.
No, it is not as Put/Get operation is not atomic, thus we cannot have thread-safety without locking underlying containers.
Regarding what you described - it is fully application specific. If you have separate threads - one for getting and processing data in cache and another one for putting data into a cache, you are responsible for locking producer-consumer to avoid freed data manipulation.

Since it is quite old thread, I'll close it, but feel free to re-open it, if you have an example that shows why we need to update the existing interface to get rid of references.

from caches.