Это как рассчитывать на силу трения об асфальт во время торможения, а не на тормоза

и вообще у меня пг %)

а может вы код накидаете? ?

я честно по описанию не совсем понял

а может вы код накидаете? ?

код к вопросу про мьютексы?) а то мало ли, уже тема убежала)

вы бы вообще прототип сделали, на тестовых сущностях

бенч там к нему

и пришли бы уже "вот тут у меня проблема" ?

блин, я всего-то спросил "насколько плохо использовать и дёргать МНОГО мьютексов" :)

мьютексы сами по себе не очень замедляют, в один поток если ? там основная проблема что блокировка для паралельных

Syscall это всегда дорого

да вот хз (*) The problem with less very often locked mutexes is that if you have too much locking in your application, it causes to much of the inter-CPU/core traffic to flush the mutex memory from the data cache of other CPUs to guarantee the cache coherency. The cache flushes are like light-weight interrupts and handled by CPUs transparently - but they do introduce so called stalls

блин, я всего-то спросил "насколько плохо использовать и дёргать МНОГО мьютексов" :)

у вас я правильно понимаю что-то типо такого: type Entity struct { profile *profile }

да?

ну да

балин, накидал и рефрешнул

я конечно не большой спец по мьютексам, но с какого перепугу вложенный профиль будет вообще дергаться

я конечно не большой спец по мьютексам, но с какого перепугу вложенный профиль будет вообще дергаться

https://play.golang.org/p/5suWDh2dpXY что-то в этом роде

а зачем вам лочить?

дык, чтобы не читать/писать в момент изменения кем-то ещё

так вы трогаете то Object, а не AuthProfile

или вы хотите трогать AuthProfile?

а чорд

ну вот, и таких объектов тыщщщи

ну это как то не совсем корректно имхо

и локов тогда будут сотни тыщщ

ну это как то не совсем корректно имхо

вот и я сомневаюсь :)

мб как вариант хранить не ссылки, а копии — но тогда при любых изменениях нужно будет все объекты обходить и заменять, тоже не айс

я сразу об этом подумал

это сожрет такое количество памяти

угу и доп.неудобства при модификации

может бизнес задачу обрисуете?

что-то мне кажется тут проблема в построении архитектуры

не с того конца копаем

ну... мониторинг оборудования ; с одной стороны - постоянный его опрос по snmp/telnet/ssh, с другой - приём и парсинг логов и snmp трапов

а объекты в которые вы так старательно кормите профили, это что?

событие на оборудовании?

само оборудование

и у них общие "поля"?

да

для чтения?

или вы пишите из сущности тоже?

ну, к примеру, в профиле указано, как ходить на железо - telnet/ssh, логин-пароль; интервалы опроса и т.д.

в основном для чтения

ну, к примеру, в профиле указано, как ходить на железо - telnet/ssh, логин-пароль; интервалы опроса и т.д.

и для нескольких железок - 1 параметр?

что-то тут подозрительно

почему?)

в том и смысл, чтобы не настраивать каждую железку индивидуально, а унифицировать конфигурацию

ну в данном случаи этот профиль будет якорить всю очередь

Так ты описал практически qt

Типа того

у вас есть телевизор, холодильник и микроволновка. Если вы их запросили одновременно, то из за общего профиля "питание" они будут выполнены один-за-одним

вернее получены

потому что на питании стоит лок на чтение

ну есть ещё rwmutex

есть

интересно без локов, чтение прокатит ?

или мы таки умрем где то по дороге

Так поеду

Типа того

нужно ваше экспертное мнение ?

На какую тему?

у человека есть телевизор, холодильник и микроволновка. У них есть ссылка на профиль "электропитание"

На какую тему?

насколько дороги очень частые локи мьютексов для проца/кеша/системы в целом? :)

при чтении любой сущности, он лочит электропитание

и сразу стоит вопрос производительности

ибо тогда "многопоточность" схлопывается до 1 потока фактически

да не схлопывается она, если rwmutex

по идее)

Не схлопывается

но вот постоянное их дёргание мне не нравится само по себе

Смотрите

Самый быстрый из синхронизаторов - atomic

а он разве не на мьютексах? ?

Ровно наоборот

я что-то думал что это такая оберточка, что бы попроще

да я даже не про скорость: у меня 90% замедления в сетевом io будет а вот нагрузка на проц, мне кажется, будет плачевна

И, если профайлер показал, что вы именно на мьютексе тратите время - можно попробовать

да я даже не про скорость: у меня 90% замедления в сетевом io будет а вот нагрузка на проц, мне кажется, будет плачевна

Не надо это все думать, надо мерять

Не надо это все думать, надо мерять

для этого сначала надо реализацию написать а я как раз думаю, как именно её писать :)

Как проще!

позже менять - почти всё переписывать нафиг

Если геттер-сеттер выделить - все изменения коснутся только его

Смотрите

погуглил тут про rw.RLock(), не совсем понимаю зачем он нужен, он же лочит на чтение. Мы же получаем все равно сможем нагадить из паралельного процеса. Или он преостанавливает, если к нам кто-то пишет?

да

все читают, но когда приходит писатель, то все ждут.

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

что мы прошли успешно RLock, и тут началась запись

и мы опять с голой попой

ну так он ждет

пока выйдет rlock

и зайдет сразу

а, с другой стороны запись тоже смотрит что бы пустой список локов был?

там безопасно все. но тут нужно смотреть, иногда выгодней юзать обычный лок.

Вроде как Prepared Statements в Го работают не так, как ожидается, и для каждого запроса создаётся новое соединение

я про ограничения PgBouncer: https://pgbouncer.github.io/faq.html#how-to-use-prepared-statements-with-transaction-pooling

вот я и пытаюсь врубиться, почему не обычный лок

для записи то нам в любом случаи его придется юзать

почему бы не залочить тогда все к едреной

если ты чаще читаешь, чем пишешь, то выгодно юзать RWMutex

если там чтение запись 1:1 или запись чаще, тогда лучше на обычный Mutex, но это пусть лучше гуру подскажут. Я в книге читал это, и встатьях часто упоминается.