DP
довольно трудно это сделать словами :)
давай я схему накидаю?
давай я схему накидаю?
довольно трудно это сделать словами :)
давай я схему накидаю?
Size: a a a
2020 June 22
RS
ну как тебе удобнее)
RS
я просто не очень понял вопрос
RS
в 2-25% случаев больше fetch чем надо было
RC
есть идеи как избежать периодических лишних запросов из singleflight cache’а?
https://play.golang.org/p/GvERr07Giy6
оборачивать чтение в эксклюзивный Lock & Unlock не хочется ибо ударит по производительности чтения.
P.S.
в playground’е эффекта не добиться, только на многоядерке и то далеко не спервого раза. Иногда рамдомно случается по той причине что 2 горутины идут в cache miss
но одна успевает пройти fetch, а вторая его ещё даже не вызывает
https://play.golang.org/p/GvERr07Giy6
оборачивать чтение в эксклюзивный Lock & Unlock не хочется ибо ударит по производительности чтения.
P.S.
в playground’е эффекта не добиться, только на многоядерке и то далеко не спервого раза. Иногда рамдомно случается по той причине что 2 горутины идут в cache miss
но одна успевает пройти fetch, а вторая его ещё даже не вызывает
повторно читать и проверять внутри lock-unlock
RS
повторно читать и проверять внутри lock-unlock
всмсл? в каком месте повторно читать?
RC
читать из мапы
с
проверять кеш уже в коллбеке видимо
RC
после Lock
RS
после Lock
это значительно замедлит чтение
RC
нет
RC
rlock остается
RC
я про дублирование проверки на наличии в кэше
RC
дублируешь ее внутрь lock перед записью в мапу
RC
если два читателя успеют обнаружить отсутствие, то дальше ты их сериализуешь в части проверки на наличие в кэше
RC
повторной проверки
с
какой смысл, fetch то все равно будет
RC
какой еще фетч
RS
дублируешь ее внутрь lock перед записью в мапу
и в чём смысл?
запрос то всё-равно полетит
запрос то всё-равно полетит
с
какой еще фетч
fetchFn который