Race condition between Cache#Set() and Cache#Del()

[jeffomatic]

Thanks for the great write-up on this exciting project. Per a note in HN from one of the maintainers, I'm inquiring here about a possible race condition between Set() and Del().

As of this writing, Set() asynchronously enqueues the actual write, where as Del() seems to synchronously update the internal store. In other words, Del() does not appear to be aware of the write buffering implemented by Set().

At first glance, this would seem to introduce a race condition for invalidation. Wouldn't it be possible for the following sequence to be incorrect?

_ := c.Set(k, v, cost)
c.Del(k)
got, ok := c.Get(k)

I think most or all client code would expect read-your-write consistency here, but it does seem like Get() could return a valid value for k despite the invalidation on the prior line.

[karlmcguire]

Thanks for posting. You're correct about that sequence. If the Set is sitting in a channel while Del is called, the Set will still go through. I'm looking into a per-item state machine solution similar to Caffeine's.

This is high priority so I'll be focusing on this the next few days.