Race issue in LFU cache replacement strategy

[andersfylling]

I just realized this. Take note of the LFU Delete method:

And how mutexes are split between the set of cached objects to reduce blocking:

The idea here is to lock the set on writes, such as deletion or creation. While changes to objects within the set would use the "shardedMutex" struct, without caring whether or not the set is blocked or not.

Taking GetChannel as an example:

We check for locks again the set, fetch the content, and then check for "possible" locks against the mutex shard for the channel object. The issue is when a delete takes place. While the set is locked, the .Val is written to without locking the relevant shard mutex. Since this is abstracted away from each other, there is no way to directly fix this without calling a mutex lock on the set and the mutex shard at the same time.

If this race happens, there will be a casting panic as the channel might have existed on extraction, but has been defined as nil before copying.

[andersfylling]

Possible fix:

Simply reference the direct value instead of the cache wrapper

[andersfylling]

I am now very tempted to just make a sync.Map cache as the default.