про это тоже была статья от авторов

чтоб каждый не писал свое

они решали задачу с ускорением этой конструкции (map + mutex) за счет кэша процессора, кажется. на мьютексе он сбрасывется.

могу соврать

не, все так

На большом количестве процессоров, чтобы между кешами не перекидывать все, не?

похоже да

Если посмотреть на код sync.RWMutex, то можно увидеть, что при блокировке на чтение, каждая горутина должна обновить поле readerCount — простой счётчик. Это делается атомарно с помощью функции из пакета sync/atomic atomic.AddInt32(). Эти функции оптимизированы под архитектуру конкретного процессора и реализованы на ассемблере.


Когда каждое ядро процессора обновляет счётчик, оно сбрасывает кеш для этого адреса в памяти для всех остальных ядер и объявляет, что владеет актуальным значением для этого адреса. Следующее ядро, прежде чем обновить счётчик, должно сначала вычитать это значение из кеша другого ядра.


На современном железе передача между L2 кешем занимает что-то около 40 наносекунд. Это немного, но когда много ядер одновременно пытаются обновить счётчик, каждое из них становится в очередь и ждёт эту инвалидацию и вычитывание из кеша. Операция, которая должна укладываться в константное время внезапно становится O(N) по количеству ядер. Эта проблема называется cache contention.

я как понял они эту проблему зарешали

в общем, моя рекомендация звучит так: забудьте про sync.Map, ничего полезного в нем для вас нет. если он вам понадобится - вы увидите это в профайлере

ну еще можно его заюзать если нужна конкурентность, но писать свою обвязку с мютекстами лениво

чушь

я, кстати, скорее имплементирую свой вариант, с раскидыванием по N map+mutex, чем возьму sync.Map. sync.Map - это же сраный динамический тип, вокруг него тоже надо строить свою обвязку с кастингом

ну никто не спорит

а что кстати скажите по поводу произовдительности на большом количестве ядер?

картинка из статьи

можно запросить у автора методику проверки, да и запилить

т.е. становится выгодно от 4 ядер?

ну по статьи - так

сам не тестил