AK
Не понимаю, с какого бодуна в доках по API Fiber'ы считаются кооперативными??
Size: a a a
2021 October 11
AK
Нам же многопоточность давным-давно завезли
BZ
разве? вроде до сих пор экспериментальная фича
BZ
но здесь речь вообще о другом. нити могут переключаться только принудительно, как и горутины к примеру
AK
Если файберы работают на разных ядрах, они могут выполняться параллельно.
Но представим ситуацию: потоков больше, чем ядер процессора. Тогда запросто один файбер в произвольном месте прерывается системным таймером. А в следующий момент - получает управление уже другой файбер, в другом потоке.
Но представим ситуацию: потоков больше, чем ядер процессора. Тогда запросто один файбер в произвольном месте прерывается системным таймером. А в следующий момент - получает управление уже другой файбер, в другом потоке.
AK
И это вполне себе вытесняющая многозадачность, а не кооперативная.
BZ
но при этом вытесняющая многозадачность будет между потоками ОС, а не нитями :)
BZ
под вытеснением нитей понимается именно то, что они переключаются внутри одного потока ОС, что работает более эффективно
BZ
переключение потоков ОС - на два порядка более тяжёлая операция, насколько я помню по С++-ным реализациям
AK
Так какая разница, кто именно переключил, ОС или планировщик?
Когда говорят о кооперативной многозадачности - речь же именно о том, что переключение происходит "контролируемо", мы всегда знаем, где нас могут прервать, и это точно не произойдёт где-то посередине c += 1
Когда говорят о кооперативной многозадачности - речь же именно о том, что переключение происходит "контролируемо", мы всегда знаем, где нас могут прервать, и это точно не произойдёт где-то посередине c += 1
BZ
в данном случае комментарий рекомендует делать Yield, чтобы не получить зависание. исходя так сказать из наихудшего сценария
AK
Не, я о том, что из устаревшего текста в документации непонятно, что совместно используемые файберами переменные нужно защищать примитивами синхронизации. Либо юзать исключительно каналы для обмена.
BZ
этот комментарий просто о другом. туда можно добавить ещё один комментарий, но логичней описать это в сведениях о выборе рантайма
AK
Т.е. yield - это и для кооп многозадачности актуально, а опасность совместного доступа к переменным - это про параллелизм и вытесняющую многозадачность. И как только в Crystal завезли preview-mt - нужно было выпиливать из доков неправду про кооп. многозадачность
BZ
ну как неправда? если у тебя два потока ОС, то две нити с вычисдениями могут их полностью оккупировать без Yield
BZ
и это не говоря о том, что фича пока что экспериментальная
BZ
про опасность совместного доступа имхо лучше писать в описании preview-mt. как и всех остальных плюсах и минусах в сравнении с дефолтной моделью
AK
Так нигде не сказано, что текст актуален только без preview-mt
BZ
мне уже надоело повторять что текст актуален и с preview-mt. я тебе даже более могу сказать - с preview-mt у тебя может быть один поток ОС. гарантий никаких этот ключ не даёт
E
Кооперативность никуда не девается при завозе вытеснения. Эти два режима не взаимоисключающие.