1:15:20 -- в оригинале фраза звучит так: "There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors." -- В компьютерных науках есть две сложные проблемы: инвалидация кэша, именование переменных и ошибка на единицу.
Лекция отличная, большое спасибо! Я пишу под Windows и всегда пользовалься нативными потоками OC для распараллеливания. Недавно попробовал работать с потоками c++. Там все продумано и логично. Код пишется легко. Но мне показалось, что внутренний библиотечный пул пытается экономить ресурсы. Скажем при 8-ми ядрах на десктопе, мне не удалось добиться одновременной работы 8-ми потоков. Работают не более 6. Остальные стоят в очереди. Еще один неприятный момент: невозможно создать поток в состоянии suspend(?) и точно отследить начало работы потока. Видимо, это плата за переносимость. Нативные потоки в Windows гибче.
Понимаю, что синглтон здесь использовался для демонстрации, но всё же скажу, что начиная с C++11 если в функции инициализируется static переменная, то это гарантировано сделает только один поток, а другие потоки не будут обращаться к неинициализированной переменной. Подробнее можно почитать: Энтони Уильямс "Практика многопоточного программирования", с. 100
Есть вероятность, что при разбиении по потокам, мультитрэйдинг не будет учитываться. Т.е. на шестиядерном проце, будет использовано только шесть потоков.
44:45 Во всех примерах, где объявляется unique_lock c defer_lock, последующий вызов lock производится на них же, а не на исходные мьютексы. Почему здесь не так ? Сработает ли unique_lock если не вызывать на них lock ??? future_status - переводится как "будущий статус".
А разве в примере на 1:00:00 не будет дедлока? sending_thread функция лочит мьютекс mt и зависает в вечном ожидании непустого буфера (не освобождая мьютекс) на строке 10. Соответственно, при вызове функции on_frame она задедлочится навсегда в ожидании мьютекса mt на строчке 18.
Ого, вот это лекции, спасибо!
Спасибо за лекцию, включил на фоне, чтобы уснуть)
1:15:20 -- в оригинале фраза звучит так: "There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors." -- В компьютерных науках есть две сложные проблемы: инвалидация кэша, именование переменных и ошибка на единицу.
Супер препод.
Лекция отличная, большое спасибо!
Я пишу под Windows и всегда пользовалься нативными потоками OC для распараллеливания. Недавно попробовал работать с потоками c++. Там все продумано и логично. Код пишется легко. Но мне показалось, что внутренний библиотечный пул пытается экономить ресурсы. Скажем при 8-ми ядрах на десктопе, мне не удалось добиться одновременной работы 8-ми потоков. Работают не более 6. Остальные стоят в очереди. Еще один неприятный момент: невозможно создать поток в состоянии suspend(?) и точно отследить начало работы потока. Видимо, это плата за переносимость. Нативные потоки в Windows гибче.
Спасибо большое!
Понимаю, что синглтон здесь использовался для демонстрации, но всё же скажу, что начиная с C++11 если в функции инициализируется static переменная, то это гарантировано сделает только один поток, а другие потоки не будут обращаться к неинициализированной переменной.
Подробнее можно почитать: Энтони Уильямс "Практика многопоточного программирования", с. 100
Есть вероятность, что при разбиении по потокам, мультитрэйдинг не будет учитываться. Т.е. на шестиядерном проце, будет использовано только шесть потоков.
44:45 Во всех примерах, где объявляется unique_lock c defer_lock, последующий вызов lock производится на них же, а не на исходные мьютексы. Почему здесь не так ? Сработает ли unique_lock если не вызывать на них lock ??? future_status - переводится как "будущий статус".
Чем Event отличается от Condition Variable? Судя по функционалу - практически одно и то же.
а как мьючить лотекс?
🤣
А разве в примере на 1:00:00 не будет дедлока?
sending_thread функция лочит мьютекс mt и зависает в вечном ожидании непустого буфера (не освобождая мьютекс) на строке 10. Соответственно, при вызове функции on_frame она задедлочится навсегда в ожидании мьютекса mt на строчке 18.
В момент вызова wait мьютекс отпускается
1:30:25 volatile
std::async(std::launch::async, ...); -- как то мало асинков, надо больше, больше!
коробит слух когда пи ти ар называют пэ тэ эр :))))