Grohuf

Ну если использовать локи так, как ты там расписывал, то конечно. При нормальном программировании в 99% случаев достаточно спинлока даже без фоллбэка на мьютекс. Вот рассмотрим простейшую концепцию мессейдж лупа. Это просто тред с очередью задач. Когда очередь пуста, естественно, поток должен засыпать, он не должен что-то там молоть, так как очередь может быть пуста длительное время. Кроме того, если задачи он обрабатывает разного рода, то потеря кэша для него не так уж страшна. Но вот потоки, которые будут класть задачи в очередь, засыпать не должны. Потому что постановка задачи в конец очереди занимает минимальное время. И тут достаточно спинлока. Поэтому и получается, что очередь должна быть защищена спинлоком, если она пуста, то поток просто сбрасывает событие и засыпает на нем. Как только в очередь будет положена первая задача, событие переходит в сигнальное состояние и поток просыпается.

Прочитай конец моей ссылки на хабр. Одна цифра. 4000.

Дело не в блокировке (время выполнения атомарной функции измеряется в наносекундах), а в смене контекста. допустим, есть 2 потока с 2 физическими ядрами, которые ковыряют сегмент памяти с атомиком; у обоих есть кэш с этой памятью. один из потоков что-то делает с памятью, вызывая блокировку кэша другого ядра. вот это заблокированное ядро - получается в поведение заложено то, что: кэш заблокирован атомиком = это ненадолго = смены контекста нет. это верно? кажется странным, судя по атомику плюсов, туда можно просунуть по размеру что-то большое, что может быть не быстрым. т.е. в рамках этой логики, можно фризить другое ядро Как я понимаю, современные атомики не фризят весь процесс общения с памятью. Атомики сейчас повсюду (это базовый примитив, на котором работает вся остальная синхронизация), а у процессоров по 16 ядер и больше. Если бы они фризили все, то ядра большую часть времени простаивали. https://habr.com/ru/companies/otus/articles/343566/ Просто он на порядок медленнее обычной операции. А влияние барьера на оптимизацию ничтожно, по сравнению с тем, что смена контекста по сути обнуляет L1 и L2 кэши. Большинство локов - это спинлоки и к смене контекста не приводят. Поэтому тормоза от них небольшие. Поэтому и локфри код особого смысла писать нет.

Дело не в блокировке (время выполнения атомарной функции измеряется в наносекундах), а в смене контекста.

На собеседовании задаю задачку. А так обычно все ограничивается std::atomic<int>. Но, конечно, как написать спинлок знать полезно. Более сложный код в большинстве случаев просто нет смысла писать. В этом нет смысла, так как в подавляющем большинстве случаев лок делается без смены контекста и обходится недорого. В тех случаях, когда происходит смена контекста, обычно, lock-free кодом не обойтись. Так что сложный lock-free код - это очень редкая специфичная задача.

Потокосрач забавен тем что почти никто из участвующих не пишет многопоточность 99% времени и не пишет топочные тесты - в последнем открыто признаются Зато каждый считает себя неебаца экспертом по теме У меня вот нет уверенности что @Just.Doit или @Grohuf могут реализовать простенький многопоточный класс интерфейс C_starts_after_A_and_B_finished из моего теста Зато обсудить как с точки зрения архитектуры компьютера сделаны memory_barrier - это они в первых рядах Может я еще Hello World не могу написать? Астрологи объявили неделю тупизны? Один кретин считает, что я не знаю gmock, другой что не умею писать многопоточный код. Вы блять свой уровень показываете, думая, что какое-то знание ваше является особенным. Не говори это Голдроботу. Он расстроится.

т.е. тебя смущает перекат от огроменной валыны а вот парирование валыны которая в 4 раза больше тебя - норм странная логика ты же понимаешь, что это просто механики избегания урона? которые пришли на замену тупому блоку который блочил всё доджить надо вовремя и в правильную сторону парировать/блокировать с последующим репостом тоже надо вовремя и далеко не всё можно И чо? А ты не в курсе, что просто поменяв скины в игрульке, можно сменить ее целевую аудиторию?

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

Блять, гроха, ебаный стыд. Я описал идею того, как это делается, и как я считаю это правильным. Я взял выраженный пример. Мне что нужно было, посидеть сейчас и повыдумывать тебе что то сложнее? С ифами и прочим? Нужно было синженерить тебе класс какимнибудь сокетом? Придумать логику, тесты к ней, и расписать? Ты сам не можешь представить себе просто работу я хуй знает, с базой? Там где у тебя паралельно connect, reconnect, exec, disconnect, stats, healthcheck, soft_stop и тебе нужно это скомутировать через логику. С очередями потоко безопасными, калбеками на пуки, таймаутами, и реконнектами скрытыми в этом классе. Но логику которого ты блять должен продумать, реализовать, и быть увереным что она отработала так как ты это нарисовал в голове посмотрев просто на цепочку EXPECT_CALL. И быть увереным что хотя бы нарисованные в голове сценарии ты сделал правильно. Не говоря уже о том чтобы это как-то зафиксировать. Это и нужно тестировать, если ты хочешь сделать надежно. Это и нужно абстрагировать. Эту логику. И это я сказал десять раз уже. Но ты тролишь тупостью "хахаха он хочет std::mutex::lock тестить". Подискутировали, спасибо хорош. Фпизду, сегодня с тобой на эту тему говорить больше не буду, невижу смысла. А зачем во всем тобой перечисленном локи? Я за пять минут написал многопоточный тест. А ебланы до сих спор спорят о возможности / уникальной сложности тестирования многопотока. Это что за язык? Js? Кто ребенка потерял? Вызовите полицию, пусть найдут его родителей

То есть, когда GR вызывает приватную функцию класса lock() - это ок. Когда я показываю, что он пишет хуйню и просто меняю переменную - это другое Ты писал: вызвать функцию а1, а2, а3. Потом проверить, что а1, а2 и а3 вызвались в этом порядке. Тебе еблану говорят, что это хуйня, а не тест. Тест, который тупо копирует содержимое функции - говно из жопы. Из экспектами он не превратится в золото.

Ну лучше как ты bool tested_flag_ = false в классы вписывать, и ассертить их после теста. Ух блять юнит тест от бога. Я уже понял, что ты ни хуя не понял, для чего написано так. Я по мнению еблана, должен был писать на каком-то фреймворке, не зная, имеете ли вы знания о нем. Ахуеть. А чего ты сам раньше свои объяснения на GMOCK не писал? Не знаешь что ли?

Ага, вижу. AddRef, RemoveRef, Release. А если тег поставить, чтоб считало с 1, то ты споткнешься на local_ptr. Во, об этом и речь. Ты в меру своего скудного разумения мокинга и тестов, собственно, и написал тест. Как умеешь, как знаешь. Такую хуйню можно изобразить только в страшном сне. Что нужно было сделать, какая библотека для мокингов это позволит сделать красиво, я уже сказал. Флажки он блять тестит. Произошел мем "я не тупой я просто тролю". Я пытался. Но ты и впрямь просто дурак. AddRef у него ручками вызывается . А если я ему скажу, что иногда реально вызывается, то у него инфаркт жопы случится. Про тест - это просто кринж. Тупоголовый еблан думает, что если он напишет EXPECT_CALL, то его дерьмо-тест станет золотым. Алхимик, ебаный. Походу зпшка в два огра и впрямь твой предел. Это пиздец, как будто с полным кретином разговариваю.

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

атомарные операции вставляют барьер памяти. Ничего удивительного. Мьютекс - это не lock inc. lock inc - это атомарный инкремент. На Windows называется InterlockedIncrement. Типичный мьютекс, доступный только в одном процессе - это спинлок (который делается на атомарных операциях) + системный мьютекс, если спинлок крутится слишком долго (в Windows эта хуйня называется критической секцией). Уход в ожидание на мьютексе, предоставляемым ядром, - очень дорогая операция. Но если все ограничивается ожиданием в спинлоке, то ожидание на критической секции достаточно не дорого.

Каким ручным управлением? Хули ты такой тупой? Там все до предела автоматизировано и везде поставлена защита от дурака. Именно поэтому была допущена такая ошибка. Запостить задачу на другой поток в хромике - это как чихнуть. Это рядовая рутинная работа, где ошибиться сложно из-за той самой защиты. Однако чел умудрился, заюзав посттаск в конструкторе, от которой, как оказалось, тогда защиты не было (хз как сейчас, вряд ли есть). Фишка тут в том, что такую ошибку хуй найдешь и удалось поймать только из-за особенности работы планирования потоков (кажись на unix системах). Для того, чтобы сделать что-то потенциально опасное, нужно при создании задачи явно указать "да, я знаю, что это опасно, но я подумал и знаю, тут будет все ок". Например, если создаешь таску с сырым указателем на объект, то его надо обернуть в base::Unretained. Если ты не работал с нормальными абстракциями тасков и таскраннеров - это твой пробел. Не надо пытаться делать вид, что все это хуйня и достаточно знания стандартной библиотеки. Ну я уже понял, что ты настолько тупой, что не догнал, что я просто максимально упростил предлагаемый тобой тест. Ты предлагал написать в коде функции лок у другого класса. Вызвать функцию у другого класса, сделать анлок у другого класса. А потом в тесте нахуячить проверку, что вызван лок у другого класса, вызвана рабочая функция у другого класса, вызван анлок у другого класса. Я написал тоже самое. Присвоил единицу переменную у другого класса и проверил что присвоена единица. Такой же идиотизм, что предлагаешь ты. Но ты настолько тупой, что ты не можешь допереть, что я просто довел до абсурда твою технику тестирования. Мы уже поняли, как ты все делаешь. Ты сам это написал.

Напомню, как пишутся тесты от GR: локи - часть имплементации объектов connection и cache и при использовании этих объектов мы не должны проверять их имплементацию (они для нас черные ящики). Мы же не проверяем, когда выделяем память в куче, что там спинлок захватывается. Однако GR на полном серьезе предлагает так тестировать. Когда нормальный юнит-тест - это когда объект считается черным ящиком и мокаются его входы и выходы и проверяется, что когда мы подаем что-то на вход, то на выходе получаем ожидаемые значения (при необходимости - в нужном порядке). Некоторые многопоточные случаи можно провеять, подавая данные на вход в нужном порядке, но обычно в случае локов нужно минимизировать места, где их нужно использовать, внимательно их просмотреть (код с локами должен быть максимально простым). И стараться не использовать локи в большей части кода. Если класс с локами не удалось сделать простым, а локи в нем необходимы по каким-то причинам (производительность, например), то тогда надо делать для него что-то вроде многопоточных фаззинг тестов.

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

Лично купишь норм компики всем нашим юзерам? То, что в датацентрах решили, что лучше покупать больше железа, чем платить зп норм разработчикам - это ни для кого не секрет. Даже изобрели специальные языки для даунов, типа голанга. да я угараю расслабься ботан я понимаю все это, но тут надо тоже понимать что 16 гб оперативной памяти это минимальный стандарт в 2025 году будет мы до сих пор поддерживаем 32 битную версию браузера Но, конечно, изменение железа юзеров вносит свои коррективы. Например, раньше мультипоточное обращение к диску только вредило. С ссд все наоборот

Лично купишь норм компики всем нашим юзерам? То, что в датацентрах решили, что лучше покупать больше железа, чем платить зп норм разработчикам - это ни для кого не секрет. Даже изобрели специальные языки для даунов, типа голанга.

примеры не ракового геймплея Пример написан в том же посте. Разуй глаза.

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

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

А кто-то говорил, что это я зашореный, так как варюсь в одной кастрюле все время.

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

Надеюсь, прокомментирует каждый пост