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

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

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

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

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

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

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

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

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

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

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

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

ну... мониторинг оборудования ; с одной стороны - постоянный его опрос по 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, но это пусть лучше гуру подскажут. Я в книге читал это, и встатьях часто упоминается.

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

потому что тогда будет, как вы сказали, "схлопывание до одного потока"

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

да

там даже скорость вообще практически не проседает, емнип.

я как-то замерял