Комментарии 8
Не смог понять, что значит зацикленный поток. Можно на котиках и собачках пояснить?
Ну это когда вместо того, чтобы на каждого котика выпускать по собачке (что дорого) и забирать обратно после сьедения котика, выпускают как минимум одну собачку, которая бегает кругами, в надежде, что скоро появится кошка и она её быстро съест и продолжит дальше бегать в цикле (отсюда — зацикленная собачка). А если будут ещё кошки появляться с частотой превышающей время поедания первой собачкой, то тогда уж так и быть, будут запускать ещё собачек на каждую кошку, или ещё несколько зацикленных собачек.
Сначала по качеству исходного текста и перевода:
> Может показаться, что глобальная очередь имеет преимущество перед локальной, но регулярная проверка глобальной очереди критична для избежания M использования только горутин из локальной очереди.
Непонятно, к чему «но», если вторая часть не противоречит первой. Надо было вводным сказать что-то вроде «Возможно, вас удивляет, что...»? Тут странность в исходном тексте.
> Постоянное упреждение (preemption)
Перевод как «упреждение» неадекватный, в данном контексте для preemption принятое и понятное слово — «вытеснение».
> В любой момент M горутин должны быть распределены между N потоками ОС
Конфликтует с последующим использованием M как системного треда (которых N, как раз по этой цитате). Лучше было бы заменить буквы, их, к счастью, достаточно :)
По содержанию:
Вообще не видно связи между выбором между work-sharing и work-stealing, и оптимизацией шедулера, точно так же как причин их жёстко противопоставлять друг другу.
Work-stealing это метод, неизбежный всегда, потому что ситуация, когда стоят ждущие процессора задачи и процессор освобождается (а другие работают и не должны отвлекаться) — типична и происходит в реальной загруженной машине много раз в секунду. «Мы сделали work stealing» звучит, поэтому, примерно как «мы наконец-то включили мозг при написании шедулера». Это, конечно, хорошо, но вряд ли заслуживает особой публикации.
Избавление от центрального мьютекса и lock-free — уже ближе к интересному (но тут популярное описание от самого Вьюкова было бы ценнее, эта тема — его давний конёк).
А вот много других интересных особенностей тут явно упущено. Например, метод и качество определения факта, что M в блокирующем системном вызове или аналогичной библиотечной функции, и реакции на неё. Согласование этого с FFI. Есть ли деление на блокирующие и неблокирующие FFI вызовы, какая граница между ними? Планируют ли они просить scheduler activations, как поддержку от ядра ОС? Ещё, есть проблема (тут, например, она под номером 58) горутин, которые не отдают управление. Элементарно забить такими все GOMAXPROCS, или намеренно, или случайно при больших вычислениях. Собираются ли решать её?
> Может показаться, что глобальная очередь имеет преимущество перед локальной, но регулярная проверка глобальной очереди критична для избежания M использования только горутин из локальной очереди.
Непонятно, к чему «но», если вторая часть не противоречит первой. Надо было вводным сказать что-то вроде «Возможно, вас удивляет, что...»? Тут странность в исходном тексте.
> Постоянное упреждение (preemption)
Перевод как «упреждение» неадекватный, в данном контексте для preemption принятое и понятное слово — «вытеснение».
> В любой момент M горутин должны быть распределены между N потоками ОС
Конфликтует с последующим использованием M как системного треда (которых N, как раз по этой цитате). Лучше было бы заменить буквы, их, к счастью, достаточно :)
По содержанию:
Вообще не видно связи между выбором между work-sharing и work-stealing, и оптимизацией шедулера, точно так же как причин их жёстко противопоставлять друг другу.
Work-stealing это метод, неизбежный всегда, потому что ситуация, когда стоят ждущие процессора задачи и процессор освобождается (а другие работают и не должны отвлекаться) — типична и происходит в реальной загруженной машине много раз в секунду. «Мы сделали work stealing» звучит, поэтому, примерно как «мы наконец-то включили мозг при написании шедулера». Это, конечно, хорошо, но вряд ли заслуживает особой публикации.
Избавление от центрального мьютекса и lock-free — уже ближе к интересному (но тут популярное описание от самого Вьюкова было бы ценнее, эта тема — его давний конёк).
А вот много других интересных особенностей тут явно упущено. Например, метод и качество определения факта, что M в блокирующем системном вызове или аналогичной библиотечной функции, и реакции на неё. Согласование этого с FFI. Есть ли деление на блокирующие и неблокирующие FFI вызовы, какая граница между ними? Планируют ли они просить scheduler activations, как поддержку от ядра ОС? Ещё, есть проблема (тут, например, она под номером 58) горутин, которые не отдают управление. Элементарно забить такими все GOMAXPROCS, или намеренно, или случайно при больших вычислениях. Собираются ли решать её?
Тема интересная, но перевод утерял множественное число много раз(поток вместо потоки, например). Выглядит как машинный перевод.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Work-stealing планировщик в Go