Это я про предыдущую тему о базе

Прошу прощения, не там пальцем провел) это на сообщение выше писал

Короче, надо навернуть атомик, ок

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

В вашем случае sync.RWMutex

Если большинство читает

И то верно

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

В любом случае хорошее правило - если читает/пишет больше одного, то мьютекс

Но все же. https://4gophers.ru/articles/konkurentnost-v-go-gonki/

Вот в статье пример, где программа с состоянием гонки не вызывает панику

(при этом, в моём вопросе не имеет значения корректность результата)

Значит ли это, что можно не заморачиваться с синхронизацией?)

Значит ли это, что можно не заморачиваться с синхронизацией?)

Гонка не вызывает панику, она вызывает непредсказуемое поведение приложения, что намного хуже чем паника.

Гонка не вызывает панику, она вызывает непредсказуемое поведение приложения, что намного хуже чем паника.

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

Тогда пожалуйста

И ты перед каждым запросом коннект типа поднимаешь?

С чего это вдруг? Речь идет вот о чем: 1. Пришел запрос от клиента, берем наш *sql.DB 2. В это время наша горутина устанавливает коннект и в переменную database.DB пишет то, что вернул sql.Open. Что это? Не гонка разве?

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

Это пока устраивает. А потом не будет устраивать, но забудется и придется искать причину ошибки. Так что лучше сразу нормально сделать.

С чего это вдруг? Речь идет вот о чем: 1. Пришел запрос от клиента, берем наш *sql.DB 2. В это время наша горутина устанавливает коннект и в переменную database.DB пишет то, что вернул sql.Open. Что это? Не гонка разве?

Блин, нет, там внутри пул из этих коннектов

Какая разница что там внутри

Это пока устраивает. А потом не будет устраивать, но забудется и придется искать причину ошибки. Так что лучше сразу нормально сделать.

+

это был вам намёк, что делом надо заниматься, а не призрачный тест кавердж блюсти

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

Какая разница что там внутри

Ты ещё мутексы мутексами оборачивай

sql.Open() возвращает у тебя в DB, в этот момент ты берешь database.DB и обращаешься к нему.

объясните ему кто-то

когда коннект установился, понятно что внутри concurrent safe

Это пока устраивает. А потом не будет устраивать, но забудется и придется искать причину ошибки. Так что лучше сразу нормально сделать.

=) это продуманное решение в пользу быстродействия. Задача была сэкономить такты на лочках при подмене одного кеша другим (кеш в сложной структуре с мапами, поэтому просто подменяем указатели). При этом какой кеш успел прочитать клиент - не принципиально, критична именно скорость ответа.

sql.Open() возвращает у тебя в DB, в этот момент ты берешь database.DB и обращаешься к нему.

В какой этот, ты делаешь Open() по сути ещё даже с базой соединение не устанавливается.

ладно, забей

Это пока устраивает. А потом не будет устраивать, но забудется и придется искать причину ошибки. Так что лучше сразу нормально сделать.

Если задача требует высокой производительности, мьютексы являются узким местом (а они не то чтобы очень быстрые) и в софте race не приведет к пиздецу то можно и выпилить.

Правда пример такого софта я не могу привести) Но есть софт где локи много выедают.

go-database-sql.org/accessing.html Perhaps counter-intuitively, sql.Open() does not establish any connections to the database, nor does it validate driver connection parameters. Instead, it simply prepares the database abstraction for later use. 

go-database-sql.org/accessing.html Perhaps counter-intuitively, sql.Open() does not establish any connections to the database, nor does it validate driver connection parameters. Instead, it simply prepares the database abstraction for later use. 

Самое интересное, что он даже не проверяет, что соединение может быть установлено. Поэтому после этого мы при ините вызываем db.Ping() Чтобы оно проверило и ругнулось в случае чего

ладно, забей

ладно, забей

Смотри https://github.com/Supme/gonder/blob/master/models/config.go#L33 Это потом используется во всём приложении и для рассылки в тысячи потоков и для статистики и для апи. Если не ограничить коннекты к базе, то база будет через какое то время делать отлуп

Правда пример такого софта я не могу привести) Но есть софт где локи много выедают.

Еще очень интересно как работает RWMutex. Допустим есть 1000 горутин, которые вызвали RLock() и в этот момент читают данные. Вызываем в другой рутине Lock(), она будет ждать пока эта 1000 дочитает, это предсказуемо. Но в тоже время, если у нас появятся еще 500 читателей, то они будут ждать пока первая 1000 дочитает, потом, когда запишется и только потом смогут получить свои данные и это мне показалось несколько странно. Потому, что за это время уже можно ответить на запросы из тех данных, что есть.

Еще очень интересно как работает RWMutex. Допустим есть 1000 горутин, которые вызвали RLock() и в этот момент читают данные. Вызываем в другой рутине Lock(), она будет ждать пока эта 1000 дочитает, это предсказуемо. Но в тоже время, если у нас появятся еще 500 читателей, то они будут ждать пока первая 1000 дочитает, потом, когда запишется и только потом смогут получить свои данные и это мне показалось несколько странно. Потому, что за это время уже можно ответить на запросы из тех данных, что есть.

Lock приоритетнее чем RLock

Смотри https://github.com/Supme/gonder/blob/master/models/config.go#L33 Это потом используется во всём приложении и для рассылки в тысячи потоков и для статистики и для апи. Если не ограничить коннекты к базе, то база будет через какое то время делать отлуп

https://github.com/Supme/gonder/blob/4f599dea4d71c1fccc472f5b4cb6c7c9cfcac671/models/config.go#L44

поднимать коннект в init, это шляпа

Lock приоритетнее чем RLock

Lock будет ждать пока существующие RLock не разблокируются. И заблокирует все новые RLock.

поднимать коннект в init, это шляпа

Нормально работает, а тот селект 1 это проверка что не голая база

Инит один раз происходит

Lock будет ждать пока существующие RLock не разблокируются. И заблокирует все новые RLock.

Да, ты же можешь изменить данные поэтому и остальные читатели ждут, потому что ты уведомил их что сейчас будешь что-то изменять.

Еще очень интересно как работает RWMutex. Допустим есть 1000 горутин, которые вызвали RLock() и в этот момент читают данные. Вызываем в другой рутине Lock(), она будет ждать пока эта 1000 дочитает, это предсказуемо. Но в тоже время, если у нас появятся еще 500 читателей, то они будут ждать пока первая 1000 дочитает, потом, когда запишется и только потом смогут получить свои данные и это мне показалось несколько странно. Потому, что за это время уже можно ответить на запросы из тех данных, что есть.

Вы прочитайте переменную и сделайте анлок. Либо атомики используйте.

Да, ты же можешь изменить данные поэтому и остальные читатели ждут, потому что ты уведомил их что сейчас будешь что-то изменять.

Логично, а вы дочитали вторую часть моего длинного сообщения?)

Нормально работает, а тот селект 1 это проверка что не голая база

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

Вы прочитайте переменную и сделайте анлок. Либо атомики используйте.

Ой, всё) Вы такие внимательные)

Логично, а вы дочитали вторую часть моего длинного сообщения?)

Я не понимаю, что показалось странным.

Ой, всё) Вы такие внимательные)

Я дочитал до конца.

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

Я не понимаю, что показалось странным.

Вторые 500 читателей появились уже после того как я уведомил, что хочу изменить данные. Что в этом странного)

=) это продуманное решение в пользу быстродействия. Задача была сэкономить такты на лочках при подмене одного кеша другим (кеш в сложной структуре с мапами, поэтому просто подменяем указатели). При этом какой кеш успел прочитать клиент - не принципиально, критична именно скорость ответа.

это случаем не с sync.Map вы имеете дело? Там как бы нету способа очистить мапу быстро

Вторые 500 читателей появились уже после того как я уведомил, что хочу изменить данные. Что в этом странного)

В том, что если вас устраивает, что они могут получить за время лока старые данные и это будет корректно - то они лочатся напрасно.

это случаем не с sync.Map вы имеете дело? Там как бы нету способа очистить мапу быстро

До свидания)

ещё разок

В том, что если вас устраивает, что они могут получить за время лока старые данные и это будет корректно - то они лочатся напрасно.

Юзайте пакет unsafe) Только осторожно)

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

После рассылок в сотни тысяч, люди сотнями в секунду открывают письма, даже, в эти моменты рестартовали, не потеряв ни одного открытого письма в статистике, потому что когда рестартуем, http сервер не слушает, он начинает слушать когда всё готово, для клиентов это затык в сети меньше чем 100мс

Юзайте пакет unsafe) Только осторожно)

какую именно возможность из него стоит изучить?

какую именно возможность из него стоит изучить?

Ну, возможность у него одна - читать и записывать произвольную память. С тех времен как конкуретное чтение мапок стало алертить он спасает)

Ну, возможность у него одна - читать и записывать произвольную память. С тех времен как конкуретное чтение мапок стало алертить он спасает)

охох) нет, это не наш выбор. мы пошли намного более безопасным и быстрым путём в вопросе параллельной записи и чтения мап

Хотя и чуть более отъедает память

охох) нет, это не наш выбор. мы пошли намного более безопасным и быстрым путём в вопросе параллельной записи и чтения мап

Шардирование?

Шардирование?

Нет. У нас задача как можно быстрее отдавать ответ, не меняя данные в процессе ответа. Поэтому мы имеем "кеш" в работе, который только читается и для всех новых клиентов подменяем указатель на новый прогретый кеш.

Поэтому в существующем кеше нет состояния гонки в мапах (они только читаются) и при этом мы имеем возможность кеш обновлять.

Нет. У нас задача как можно быстрее отдавать ответ, не меняя данные в процессе ответа. Поэтому мы имеем "кеш" в работе, который только читается и для всех новых клиентов подменяем указатель на новый прогретый кеш.

А если в момент подмены ещё и сборщик придёт?

ERROR: S client not available

А если в момент подмены ещё и сборщик придёт?

Помашем ему ручкой)

Не понял вашего вопроса

Если горутины уже не будут ссылаться на старый кеш - он его соберет

Если будут ссылаться - не соберет. Логично же?

Не понял вашего вопроса

И попортит данные предыдущие

И попортит данные предыдущие

Поясните?

А как вы заполняете второй кэш?

Указатель будет замкнут в горутине. Почему сборщик может попортить данные?

А как вы заполняете второй кэш?

В отдельной горутине

Там все медленные процессы хождения в базу и подготовки данных

А если в момент подмены ещё и сборщик придёт?

Он их не соберет, пока используется.

Нет. У нас задача как можно быстрее отдавать ответ, не меняя данные в процессе ответа. Поэтому мы имеем "кеш" в работе, который только читается и для всех новых клиентов подменяем указатель на новый прогретый кеш.

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

Там все медленные процессы хождения в базу и подготовки данных

А на основе чего они заполняются?

По порядку)

А, понял рабочая ссылка одна, а меняем её на обновлённую в которой данные, ок.

По порядку)

Да не, можно не отвечать уже) Я понял, тогда ваш костыль будет норм работать)

1. На каждый запрос мы в канал пишем id сущности которую запросили 2. В отдельной горутине канал слушаем и проверяем, что данные устарели (были обновлены n секунд назад) или вообще не сущетсвуют 3. Обновляем 4. Меняем указатель

Магия, но быстрее решения не придумал

Магия, но быстрее решения не придумал

а bigcache пробовали? Я не уверен что он быстрее, но он очень интересно хранит данные в одной куче и по оффсетам достает. Должно быть очень быстро и конкуретно)

а bigcache пробовали? Я не уверен что он быстрее, но он очень интересно хранит данные в одной куче и по оффсетам достает. Должно быть очень быстро и конкуретно)

Нет, зачем, если мы из стандартных инструментов уже получаем решение?

Магия, но быстрее решения не придумал

Есть вероятность, что все гоурутины встанут в ожидании, пока наполнитель кэша будет обрабатывать данные на пополнение кэша.

а, кстати, я его изучал. Шардирование - тоже рассматривали как вариант. Но он внутри все равно с лочками. И в нашем варианте выглядит все проще.

Есть вероятность, что все гоурутины встанут в ожидании, пока наполнитель кэша будет обрабатывать данные на пополнение кэша.

Почему?

А какая нагрузка то?

А какая нагрузка то?

Да никакой) просто развлекаюсь

Почему?

Потому что запись в канал блокирующая операция (в которой, кстати мютексы используются) и пока данные не изымут из канала горутина будет висеть. Либо делать буфер с запасом.

В проде сейчас в среднем 800 запросов в секунду, но там пхп и тоже все оптимизированно, что даже на 10% проц не грузит.

Гошка с шаблонами штатными гигабитный канал запросто забивала, причём был ещё xorm но с включеным кэшем

Потому что запись в канал блокирующая операция (в которой, кстати мютексы используются) и пока данные не изымут из канала горутина будет висеть. Либо делать буфер с запасом.

я подумал и над этим. хотите решение покажу?)

я подумал и над этим. хотите решение покажу?)

Покажите.

Покажите.

select{ case ch <- id: case default: }