Race condition in @cached

[JelleZijlstra]

The @cached decorator sets its result in the cache as follows:

            result = await func(*args, **kwargs)

            try:
                await cache.set(cache_key, result, ttl=ttl)
            except Exception:
                logger.exception("Unexpected error with %s", cache)

This is vulnerable to a race condition. Assume that two processes, A and B, are both calling the same @cached function with the same arguments. Then the following sequence of events can happen:

1. process A calls the function
2. process B calls the function
3. process A sees a cache miss and retrieves the ground truth data
4. the ground truth data changes
5. process B also sees a cache miss and retrieves ground truth
6. process B gets scheduled again and sets the result in the cache
7. process A gets scheduled and sets stale data in the cache

This can be fixed for at least memcache by using gets to get a CAS token, and then setting to the cache only if the CAS token is still valid.

[argaen]

Yeah, I had a thread in my mind thinking about this. Before implementing this I wanted to check something that will work for the 3 implemented backends. I believe for Redis using something like a token would work and in the memory one since its not distributed it should be easy.

In the same line, related to this is #27 (http://www.sobstel.org/blog/preventing-dogpile-effect/) which would solve this as a side effect. I need to think if it does worth it to offer the functionality explicitly for each backend or by just offering the "dogpile" plugin and let the user decide to use it or not would be enough.

Any opinion is welcome

[argaen]

Closing in favor of #187 where I'll keep track of possible cases until locking is implemented