4. Примитивы синхронизации II: spin, conditional. Обработка сигналов

[@Cadovvl]

Отличные лекции. Спасибо.

[@ValentinNechayev]

[55:50 и вокруг] В лекции неправда: notifyOne, notifyAll будут корректно работать, даже если их вынести из-под мьютекса. Причина в том,, что собственно модификация наблюдаемых данных происходит всё равно под локом, так что вмешательство 1-го треда в это время невозможно, пока второй тред не уйдёт в wait(). Но если второй проверил и ушёл в wait(), то первый добавил данные до входа второго в блокировку, значит, второй проверил наличие нужного состояния. В любом варианте, работа в порядке: захватил - проверил, что нет нужного - ушёл в спячку - гарантирует, что спячка будет только если данных нет, ситуации с описанным разрывом не будет. А вот spurious wakeups в этом варианте, да, чаще. Но notify вне лока раньше было иногда эффективнее, если не было переноса блокировки между примитивами (типа futex). Сейчас она обычно есть и смысла делать notify вне лока уже нет.

[@fisyamaloy1754]

1:29:30 компилятор разве не может оптимизировать ту константу и просто подставлять в cout единицу?

[@YoutubeFrogOfHell]

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

[@dolovnyak]

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

[@Re_murr]

Возможно это у меня такое восприятие, но по моему здесь лектор немного смешал в кучу понятия CAS и "без-перехода-в-кернел-спейс". Ведь можно сделать честный мьютекс с ожиданием через кернел-спейс на CAS операции и 1 инте. И также можно сделать атомик-инт без CAS инструкции используя flag+victim подход из кода mutex из прошлой лекции. То есть SpinLock = "лок-без-перехода-в-кернел-спейс", а CAS - это просто более быстрый и удобный способ организовать барьер. Одно не требует другого

[@ValentinNechayev]

Kernel или user land в общем случае ни при чём. Главные вещи тут следующие: Если нет возможности довериться кому-то на "разбуди когда освободится", пригоден только спинлок. _Обычно_, да, это в ядре. Явные случаи - например, когда один из участников - обработчик прерывания типа top half: он не имеет права спать, он должен отработать (как можно быстрее) и завершиться. Но бывает такое и в userland, когда не хотят или не могут полагаться на диспетчер. Если можно уйти в спячку - это семафор (подразумевается, с очередью) или мьютекс (у них есть пересечение, но бывает семафор не мьютекс и мьютекс не семафор). Есть и в userland, и в ядре тоже есть: в Linux это вызовы типа down, down_interuptible... Там может покрутиться в режиме спинлока и затем увести весь тред в спячку. Это используется, когда участники - обычные треды или bottom half обработчики прерываний (которые давно загнаны под ядерные треды типа ksoftirqd). PS: ядерный механизм sleep/wakeup это полнй аналог и предшественник condvars.

[@ValentinNechayev]

1. The new thread inherits a copy of the creating thread's signal mask (pthread_sigmask(3)). И что тут экзотического? всё логично. 2. Давно уже есть signalfd, sigtimedwait и т.д., которые переводят обработку сигналов в синхронный стиль. Если упоминать вообще сигналы, надо упоминать и эти средства. Про непотерю соединения при рестарте sshd: sshd форкается и соединение обрабатывается отдельным процессом (точнее, несколькими - для секьюрити часть действий вынесена в отдельные сильно ограниченные процессы). Вообще надо бы это знать, если рассказывать про такие средства.

[@manOfPlanetEarth]

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

[@Re_murr]

Здесь объясняется концепция параллельного программирования. От языка она не зависит. Для демонстрации различных конструкций используются популярные и всем известные языки или даже псевдокод

[@manOfPlanetEarth]

@@Re_murr "всем известные языки" а че ты за всех говоришь? охереть, ты типан.

[@Re_murr]

@@manOfPlanetEarth Не надо демагогии )

[@manOfPlanetEarth]

@@Re_murr не надо подмены понятий. я тебе всё конкретно сказал. демагогией тут ты занялся именно этим сообщением.

[@Re_murr]

@@manOfPlanetEarth Забавно наблюдать как "конкретный пацан" пишет коменты к видео о многопоточном программировании.. )) Ну, в принципе, почему бы и нет. Но некий диссонанс все таки у меня это вызывает )