Программирование[11]

Grohuf написал 32 минуты назад:

Olololnet написал 2 часа назад:

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

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

допустим, есть 2 потока с 2 физическими ядрами, которые ковыряют сегмент памяти с атомиком; у обоих есть кэш с этой памятью. один из потоков что-то делает с памятью, вызывая блокировку кэша другого ядра. вот это заблокированное ядро - получается в поведение заложено то, что: кэш заблокирован атомиком = это ненадолго = смены контекста нет. это верно? кажется странным, судя по атомику плюсов, туда можно просунуть по размеру что-то большое, что может быть не быстрым. т.е. в рамках этой логики, можно фризить другое ядро

Olololnet написал 3 минуты назад:

Grohuf написал 35 минут назад:

Olololnet написал 2 часа назад:

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

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

допустим, есть 2 потока с 2 физическими ядрами, которые ковыряют сегмент памяти с атомиком; у обоих есть кэш с этой памятью. один из потоков что-то делает с памятью, вызывая блокировку кэша другого ядра. вот это заблокированное ядро - получается в поведение заложено то, что: кэш заблокирован атомиком = это ненадолго = смены контекста нет. это верно? кажется странным, судя по атомику плюсов, туда можно просунуть по размеру что-то большое, что может быть не быстрым. т.е. в рамках этой логики, можно фризить другое ядро

Как я понимаю, современные атомики не фризят весь процесс общения с памятью. Атомики сейчас повсюду (это базовый примитив, на котором работает вся остальная синхронизация), а у процессоров по 16 ядер и больше. Если бы они фризили все, то ядра большую часть времени простаивали.

https://habr.com/ru/companies/otus/articles/343566/

Просто он на порядок медленнее обычной операции. А влияние барьера на оптимизацию ничтожно, по сравнению с тем, что смена контекста по сути обнуляет L1 и L2 кэши.

Большинство локов - это спинлоки и к смене контекста не приводят. Поэтому тормоза от них небольшие. Поэтому и локфри код особого смысла писать нет.

Спинлоки юзеровские плохие в первую очередь потому что они жрут CPU. Раз они жрут CPU, то они тратят свой квант времени выделенный им шедулером. Лок освободился, а процесс идет нахуй, потому что ой сорри ты потратил свое время. Мутехи которые от ОС идут, насколько я знаю, это обходят несколько, плюс фалбек на "реально" мутех прикрывает.

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

https://www.realworldtech.com/forum/?threadid=189711&curpostid=189723

И отдельно кекнуть с топиков

GoldRobot написал 46 минут назад:

Спинлоки юзеровские плохие в первую очередь потому что они жрут CPU. Раз они жрут CPU, то они тратят свой квант времени выделенный им шедулером. Лок освободился, а процесс идет нахуй, потому что ой сорри ты потратил свое время. Мутехи которые от ОС идут, насколько я знаю, это обходят несколько, плюс фалбек на "реально" мутех прикрывает.

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

 

https://www.realworldtech.com/forum/?threadid=189711&curpostid=189723

 

И отдельно кекнуть с топиков

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

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

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

GoldRobot написал 8 минут назад:

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

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

Ну если использовать локи так, как ты там расписывал, то конечно. При нормальном программировании в 99% случаев достаточно спинлока даже без фоллбэка на мьютекс.

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

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

Just.Doit написал 5 часов назад:

Vova написал 12 часов назад:

Кто-то когда то наблюдал поведение описанное этим долбаебом в таком коде? Нет?

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

Не могу

Ты можешь?

Воспроизведи или пиздабол

Или скинь видео где другой чел воспроизводит

Ладно я за тебя нашел этот код

Вот смотри - можешь потыкать кнопку запуска

https://coliru.stacked-crooked.com/a/f6bb6c003fe8731e

Ну что может посмотрим в что он компилируется - перестановки оптимизации и вот это все

Неужели memory_order_seq_cst и memory_order_acquire / memory_order_release компилируются в идентичный код

КТО БЫ МОГ ПОДУМАТЬ

Чел  там оригинале джава 

АХХАХААХХААХ

сука аутист

вова даже не понял про что речь шла и пошел доказывать что оно не правильное 

ахахаххаха

Just.Doit написал 26 минут назад:

АХХАХААХХААХ

сука аутист

вова даже не понял про что речь шла и пошел доказывать что оно не правильное 

ахахаххаха

 

О речь шла в моем посте который ты заквотил?

Думаю никто лучше меня не понимает О ЧЕМ ШЛА РЕЧЬ В МОЕМ ПОСТЕ

Index написал 30 минут назад:

Чел  там оригинале джава 

 

Не спорю

Ну воспроизведи на джаве

Вот мой пост и я утверждаю что того что на скриншоте в видео не произойдет

ты еще и отказываешься принимать реальность и учиться на ошибках 

Just.Doit написал 2 минуты назад:

ты еще и отказываешься принимать реальность и учиться на ошибках 

С удовольствие поучусь на ошибках

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

Я утвержлал что код описанный в видео не выдаст случая Панда победила и Котик победил

Я нашел такой же код на С++ - запустил несколько раз и такоего случая не случилось

Кажется я как всегда оказался прав

То что автор видео описывает возможный случай Панда победила и Котик победил - это реальность

То что мой такой же код на С++ такого случая не выдает - тоже реальность

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

Как говорится повторение - мать учения

Vova написал 8 минут назад:

Я нашел такой же код на С++

причем здесь с++ долбаебушка

Just.Doit написал Только что:

Vova написал 9 минут назад:

Я нашел такой же код на С++

причем здесь с++ долбаебушка

При том что там точно такие же концепии имеются acquire / release vs volatile

И при том что мне было проще найти нужный код описанный в видео на С++

Ну если пользователи данного топика получают другой результат на Java - буду рад увидеть их скриншоты и ссылку на код

Grohuf написал 12 часов назад:

Olololnet написал 13 часов назад:

вживую кто-нибудь лок фри видел в боевых задачах?

На собеседовании задаю задачку.

Челы реально верят, что возможно написать тест который 100% отловят ошибки concurrency?
Так буквально это ошибки которые рандомно появляются и ваш тест их вообще может никогда не отловить


О чем спор то идет теперь?)))

Drakonian написал 18 минут назад:

Челы реально верят, что возможно написать тест который 100% отловят ошибки concurrency?

Ты в это веришь?

Grohuf написал 14 часов назад:

GoldRobot написал 14 часов назад:

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

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

Ну если использовать локи так, как ты там расписывал, то конечно. При нормальном программировании в 99% случаев достаточно спинлока даже без фоллбэка на мьютекс.

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

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

Ты похоже опять про разное. "что-то там молотить" это о дерганья атомиков в спинлоке. 

Брат, прочитай внимательнее что я написал пожалуйста, и что линух написал. Ладно голдробот ничего не понимает, потому что у него зп два огра, но линух то секет? Или нет?

Drakonian написал 1 час назад:

Челы реально верят, что возможно написать тест который 100% отловят ошибки concurrency?
Так буквально это ошибки которые рандомно появляются и ваш тест их вообще может никогда не отловить


О чем спор то идет теперь?)))

а ты можешь написать тест который 100% отловят ошибки не конкаренси?

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