@39:48 Если делать по аналогии c конструктором std::thread, то сигнатура метода submit() должна принимать rvalue reference - submit(Task&& task). Тогда вам не придется копировать и мувить input Functions (Tasks).
Ага, тоже смотрю лекции периодически! Офигенные лекции, очень интересно Немного завидую ребятам с физтеха, что у них есть возможность пройти такой потрясный курс Вам очень повезло с таким преподавателем!)
Так можно чего нет то. Есть репозиторий с курсом, который, к сожалению скрыт. Но там можно проявить смекалку и найти его ;) Тут надо сделать одно замечание. Надо понимать как Ось устроенна. Роман начинает с достаточно высоких абстракций, подразумевая что человек если не знает, то хотя бы догадывается как в самом низу это работает. Я потратил примерно 3-4 месяца что бы пройти mit 6.s081. Вернулся опять к этому курсу. Теперь все гораздо понятнее о чем вообще речь. UPD: вон внизу в комментах жалуются что "всё в вакууме". После прохождения 6.s081 я вполне себе чувствую что происходит.
Роман, а почему в очереди задач не заменить мьютекс и кондвар обычным семафором? Ну да, он не такой модный и быстрый, как кондвар и фьютекс, ну так ведь и мьютекс тоже? Тоесть, занятый мьютекс, усыпляющий наш поток на уровне ядра, вместо того чтобы покрутить цикл в ожидании, и так уже убивает перформанс. Так чего тогда не упростить все и не заменить семафором?
чтобы не жечь cpu (не спин-лочиться на cpu) consumer-producer pattern реализуется с помощью wait/notify (во многих языках, не только в C++). (например, в Java 1.2 (2000 год) wait/notify это методы класса Object. Из вызов требует synchronize block). Спустя декаду, в с++11 эти методы реализовали в std::condition_variable. А метод wait() требует std::unique_lock&
@@apivovarov2 Ну так, мьютекс, если он занят, тут же усыпляет наш поток на уровне ядра (очень дорогая операция которой мы хотели бы избежать). А кондвар требует захвата мьютекса. Тогда в чем выигрыш от танцев с бубном вокруг кондвара? Мы ведь все так же блочимся на уровне ядра, в случае неудачной попытки захвата мьютекса?
В конце прошлой лекции (лекции №2) он сказал, что есть spin-locks, а есть mutexes. Spin-locks крутятся в while, а внутри вызывают pause (например _mm_pause() или __asm volatile ("pause" ::: "memory")) чтобы поменьше нажигать эл-ва и дать соседнему hyperthread тоже поработать. Если кручение задерживается на долго, то можно сделать thread::yield() чтобы планировщик снял задачу с cpu core и перезапланировал её. Так или иначе задача будет крутиться на cpu core и потреблять эл-во. Да, меньше энергии в отличие от пустого while цикла. Чтобы радикально сократить потребление энергии - можно использовать mutex - он сделан на основе wait/notify. В частности рекомендовалось реализовать mutex самим, а реализацию wait/notify взять из linux libc - syscall futex. Про семафоры пока ничего не было.
@@apivovarov2 Про спин-локи понятно. Я недоумеваю вот над чем. У нас есть новый, быстрый кондвар, но его работа базируется на захвате древнего тормозного мьютекса, который, при неудачной попытке захвата, все так-же блокирует поток и руинит нам весь перформанс. В чем суть улучшения тогда?
Спустя пару месяцев неосознания я наконец-то начал понимать Concurrency. Спасибо за лекцию!
@39:48 Если делать по аналогии c конструктором std::thread, то сигнатура метода submit() должна принимать rvalue reference - submit(Task&& task). Тогда вам не придется копировать и мувить input Functions (Tasks).
будут записи практики, как в прошлом году?? поднимаю свой уровень понимания concurrency на вашем курсе)
Ага, тоже смотрю лекции периодически! Офигенные лекции, очень интересно
Немного завидую ребятам с физтеха, что у них есть возможность пройти такой потрясный курс
Вам очень повезло с таким преподавателем!)
55:43 Conditional Variable
Классно лектор рассказывает! А можно пройти этот курс людям с улицы или это только для слушателей курса?
Так можно чего нет то. Есть репозиторий с курсом, который, к сожалению скрыт. Но там можно проявить смекалку и найти его ;)
Тут надо сделать одно замечание. Надо понимать как Ось устроенна. Роман начинает с достаточно высоких абстракций, подразумевая что человек если не знает, то хотя бы догадывается как в самом низу это работает. Я потратил примерно 3-4 месяца что бы пройти mit 6.s081. Вернулся опять к этому курсу. Теперь все гораздо понятнее о чем вообще речь.
UPD: вон внизу в комментах жалуются что "всё в вакууме". После прохождения 6.s081 я вполне себе чувствую что происходит.
@@ВадимШатов-з2й скажи подробнее про смекалку пожалуйста )
@user-uq7ri1pz2c смекалистый, не подскажешь как это сделать?
@@ВадимШатов-з2й смекалистый, не подскажешь как это сделать?
Смысл этих курсов без актуальных исходников? Так себе.
Роман, а почему в очереди задач не заменить мьютекс и кондвар обычным семафором? Ну да, он не такой модный и быстрый, как кондвар и фьютекс, ну так ведь и мьютекс тоже? Тоесть, занятый мьютекс, усыпляющий наш поток на уровне ядра, вместо того чтобы покрутить цикл в ожидании, и так уже убивает перформанс. Так чего тогда не упростить все и не заменить семафором?
чтобы не жечь cpu (не спин-лочиться на cpu) consumer-producer pattern реализуется с помощью wait/notify (во многих языках, не только в C++). (например, в Java 1.2 (2000 год) wait/notify это методы класса Object. Из вызов требует synchronize block). Спустя декаду, в с++11 эти методы реализовали в std::condition_variable. А метод wait() требует std::unique_lock&
@@apivovarov2 Ну так, мьютекс, если он занят, тут же усыпляет наш поток на уровне ядра (очень дорогая операция которой мы хотели бы избежать). А кондвар требует захвата мьютекса. Тогда в чем выигрыш от танцев с бубном вокруг кондвара? Мы ведь все так же блочимся на уровне ядра, в случае неудачной попытки захвата мьютекса?
В конце прошлой лекции (лекции №2) он сказал, что есть spin-locks, а есть mutexes. Spin-locks крутятся в while, а внутри вызывают pause (например _mm_pause() или __asm volatile ("pause" ::: "memory")) чтобы поменьше нажигать эл-ва и дать соседнему hyperthread тоже поработать. Если кручение задерживается на долго, то можно сделать thread::yield() чтобы планировщик снял задачу с cpu core и перезапланировал её. Так или иначе задача будет крутиться на cpu core и потреблять эл-во. Да, меньше энергии в отличие от пустого while цикла. Чтобы радикально сократить потребление энергии - можно использовать mutex - он сделан на основе wait/notify. В частности рекомендовалось реализовать mutex самим, а реализацию wait/notify взять из linux libc - syscall futex. Про семафоры пока ничего не было.
Лучше не использовать слово "ядро" - неоднозначный термин. может это cpu core, а может OS kernel.
@@apivovarov2 Про спин-локи понятно. Я недоумеваю вот над чем. У нас есть новый, быстрый кондвар, но его работа базируется на захвате древнего тормозного мьютекса, который, при неудачной попытке захвата, все так-же блокирует поток и руинит нам весь перформанс. В чем суть улучшения тогда?
Без обид, но объясняет не внятно, всё в вакууме. Догадайтесь, представьте, возможно...
Я уверен, что можно объяснить намного понятнее и яснее.
Правильно: невнятно