[55:50 и вокруг] В лекции неправда: notifyOne, notifyAll будут корректно работать, даже если их вынести из-под мьютекса. Причина в том,, что собственно модификация наблюдаемых данных происходит всё равно под локом, так что вмешательство 1-го треда в это время невозможно, пока второй тред не уйдёт в wait(). Но если второй проверил и ушёл в wait(), то первый добавил данные до входа второго в блокировку, значит, второй проверил наличие нужного состояния. В любом варианте, работа в порядке: захватил - проверил, что нет нужного - ушёл в спячку - гарантирует, что спячка будет только если данных нет, ситуации с описанным разрывом не будет. А вот spurious wakeups в этом варианте, да, чаще. Но notify вне лока раньше было иногда эффективнее, если не было переноса блокировки между примитивами (типа futex). Сейчас она обычно есть и смысла делать notify вне лока уже нет.
Возможно это у меня такое восприятие, но по моему здесь лектор немного смешал в кучу понятия CAS и "без-перехода-в-кернел-спейс". Ведь можно сделать честный мьютекс с ожиданием через кернел-спейс на CAS операции и 1 инте. И также можно сделать атомик-инт без CAS инструкции используя flag+victim подход из кода mutex из прошлой лекции. То есть SpinLock = "лок-без-перехода-в-кернел-спейс", а CAS - это просто более быстрый и удобный способ организовать барьер. Одно не требует другого
Kernel или user land в общем случае ни при чём. Главные вещи тут следующие: Если нет возможности довериться кому-то на "разбуди когда освободится", пригоден только спинлок. _Обычно_, да, это в ядре. Явные случаи - например, когда один из участников - обработчик прерывания типа top half: он не имеет права спать, он должен отработать (как можно быстрее) и завершиться. Но бывает такое и в userland, когда не хотят или не могут полагаться на диспетчер. Если можно уйти в спячку - это семафор (подразумевается, с очередью) или мьютекс (у них есть пересечение, но бывает семафор не мьютекс и мьютекс не семафор). Есть и в userland, и в ядре тоже есть: в Linux это вызовы типа down, down_interuptible... Там может покрутиться в режиме спинлока и затем увести весь тред в спячку. Это используется, когда участники - обычные треды или bottom half обработчики прерываний (которые давно загнаны под ядерные треды типа ksoftirqd). PS: ядерный механизм sleep/wakeup это полнй аналог и предшественник condvars.
1. The new thread inherits a copy of the creating thread's signal mask (pthread_sigmask(3)). И что тут экзотического? всё логично. 2. Давно уже есть signalfd, sigtimedwait и т.д., которые переводят обработку сигналов в синхронный стиль. Если упоминать вообще сигналы, надо упоминать и эти средства. Про непотерю соединения при рестарте sshd: sshd форкается и соединение обрабатывается отдельным процессом (точнее, несколькими - для секьюрити часть действий вынесена в отдельные сильно ограниченные процессы). Вообще надо бы это знать, если рассказывать про такие средства.
Здесь объясняется концепция параллельного программирования. От языка она не зависит. Для демонстрации различных конструкций используются популярные и всем известные языки или даже псевдокод
@@manOfPlanetEarth Забавно наблюдать как "конкретный пацан" пишет коменты к видео о многопоточном программировании.. )) Ну, в принципе, почему бы и нет. Но некий диссонанс все таки у меня это вызывает )
Отличные лекции. Спасибо.
было бы супер получить какие-то материалы или, возможно, ресурсы попрактикроваться, может лабы остались у кого-то?
[55:50 и вокруг] В лекции неправда: notifyOne, notifyAll будут корректно работать, даже если их вынести из-под мьютекса. Причина в том,, что собственно модификация наблюдаемых данных происходит всё равно под локом, так что вмешательство 1-го треда в это время невозможно, пока второй тред не уйдёт в wait(). Но если второй проверил и ушёл в wait(), то первый добавил данные до входа второго в блокировку, значит, второй проверил наличие нужного состояния. В любом варианте, работа в порядке: захватил - проверил, что нет нужного - ушёл в спячку - гарантирует, что спячка будет только если данных нет, ситуации с описанным разрывом не будет.
А вот spurious wakeups в этом варианте, да, чаще. Но notify вне лока раньше было иногда эффективнее, если не было переноса блокировки между примитивами (типа futex). Сейчас она обычно есть и смысла делать notify вне лока уже нет.
а возможно ли где-то пдфку лабораторной работы получить?
Возможно это у меня такое восприятие, но по моему здесь лектор немного смешал в кучу понятия CAS и "без-перехода-в-кернел-спейс". Ведь можно сделать честный мьютекс с ожиданием через кернел-спейс на CAS операции и 1 инте. И также можно сделать атомик-инт без CAS инструкции используя flag+victim подход из кода mutex из прошлой лекции.
То есть SpinLock = "лок-без-перехода-в-кернел-спейс", а CAS - это просто более быстрый и удобный способ организовать барьер. Одно не требует другого
Kernel или user land в общем случае ни при чём. Главные вещи тут следующие:
Если нет возможности довериться кому-то на "разбуди когда освободится", пригоден только спинлок. _Обычно_, да, это в ядре. Явные случаи - например, когда один из участников - обработчик прерывания типа top half: он не имеет права спать, он должен отработать (как можно быстрее) и завершиться. Но бывает такое и в userland, когда не хотят или не могут полагаться на диспетчер.
Если можно уйти в спячку - это семафор (подразумевается, с очередью) или мьютекс (у них есть пересечение, но бывает семафор не мьютекс и мьютекс не семафор). Есть и в userland, и в ядре тоже есть: в Linux это вызовы типа down, down_interuptible... Там может покрутиться в режиме спинлока и затем увести весь тред в спячку. Это используется, когда участники - обычные треды или bottom half обработчики прерываний (которые давно загнаны под ядерные треды типа ksoftirqd).
PS: ядерный механизм sleep/wakeup это полнй аналог и предшественник condvars.
1:29:30 компилятор разве не может оптимизировать ту константу и просто подставлять в cout единицу?
1. The new thread inherits a copy of the creating thread's signal mask (pthread_sigmask(3)). И что тут экзотического? всё логично.
2. Давно уже есть signalfd, sigtimedwait и т.д., которые переводят обработку сигналов в синхронный стиль. Если упоминать вообще сигналы, надо упоминать и эти средства.
Про непотерю соединения при рестарте sshd: sshd форкается и соединение обрабатывается отдельным процессом (точнее, несколькими - для секьюрити часть действий вынесена в отдельные сильно ограниченные процессы). Вообще надо бы это знать, если рассказывать про такие средства.
пролистал выпуски в этом плейлисте: я так понял, что используются разные языки: и джава и что-то и семейства с - верно?
Здесь объясняется концепция параллельного программирования. От языка она не зависит. Для демонстрации различных конструкций используются популярные и всем известные языки или даже псевдокод
@@Re_murr
"всем известные языки"
а че ты за всех говоришь? охереть, ты типан.
@@manOfPlanetEarth Не надо демагогии )
@@Re_murr
не надо подмены понятий. я тебе всё конкретно сказал. демагогией тут ты занялся именно этим сообщением.
@@manOfPlanetEarth Забавно наблюдать как "конкретный пацан" пишет коменты к видео о многопоточном программировании.. ))
Ну, в принципе, почему бы и нет. Но некий диссонанс все таки у меня это вызывает )