Comments 17
Прям глаз режет этот ваш «Шедулер», кто не работал с какой либо ОС вплотную, не поймут, что вы говорите о Планировщике (scheduler).
угу, и «преемптивность» — есть же нормальный термин — вытесняющая многозадачность…
Знаете анекдот? Оживили Сталина. Он очнулся, поглядел и говорит:
— Давайте расстреляем всех министров и покрасим Кремль в зелёный цвет.
— А Кремль зачем красить?
— Я рад, что по первому вопросу возражений нет.
:)
Я вот инверсию приоритетов не описал, вот что жалко… ладно, наверное, напишу про Планировщик при случае, там и отмечу.
— Давайте расстреляем всех министров и покрасим Кремль в зелёный цвет.
— А Кремль зачем красить?
— Я рад, что по первому вопросу возражений нет.
:)
Я вот инверсию приоритетов не описал, вот что жалко… ладно, наверное, напишу про Планировщик при случае, там и отмечу.
Конечно можно было продолжить комментировать названия:), но…
Разве нельзя сделать сигнатуру функции переключение контекста без третьего аргумента, я имею в виду спинлок. Ведь это проще сделать в вызывающей функции?
Разве нельзя сделать сигнатуру функции переключение контекста без третьего аргумента, я имею в виду спинлок. Ведь это проще сделать в вызывающей функции?
Пожалуйста, не переводите threads как нити, в русских переводах есть устоявшийся термин «потоки».
нити — это как раз очень правильный и удобный перевод.
Потоков много разных, особенно если дело доходит до какого-нибудь с++, а нити — сразу понятно, о чём речь.
Потоков много разных, особенно если дело доходит до какого-нибудь с++, а нити — сразу понятно, о чём речь.
не то, что бы я прям вот много такого читаю по-русски, но мы между собой нити называем нитями. Хотя, сейчас всё больше акторы, но всё равно, когда какие-то разборки в глубь, то так и говорим «какой там шедулер у этого класса акторов, дефолтный? и им кадому по нити jvm дает, или кучу на одну вешает?»
Тогда возникнет проблема в термине «streams».
А может попробовать 2-steps scheduler:
1. Select process.
2. Select thread
1. Select process.
2. Select thread
Вытесняющая многозадачность не эквивалентна вызову yield()
Потому что вызов попортит стек. В актуальных ОС стек можно поставить в середину данных и крутиться в юзермодном спинлоке (потом esp вернуть обратно) и никакое вытеснение не испортит эти данные. Intel даже ввела специальный механизм, чтобы при получении прерывания стек перемещался в kernel space и юзер стек не портился.
Потому что вызов попортит стек. В актуальных ОС стек можно поставить в середину данных и крутиться в юзермодном спинлоке (потом esp вернуть обратно) и никакое вытеснение не испортит эти данные. Intel даже ввела специальный механизм, чтобы при получении прерывания стек перемещался в kernel space и юзер стек не портился.
Мне кажется, Вы немного смешиваете разные вещи.
1. Статья описывает реализацию в ядре. user mode в ней не затрагивается почти совсем.
2. Если вызов функции (yield — функция) портит стек, то компилятор надобно починить или заменить на исправный. Если стек портит реализация — её не надо было писать с ошибками. Если Вы её вызвали, а SP смотрит не на стек — ну, наверное, Вы погорячились.
3. Как Вы совершенно справедливо заметили (ну и, если Вы внимательно читали, у меня это написано сразу после примера кода «cpu_tss[ncpu].esp0 = (addr_t)t->kstack_top;») — Интеловские, да и все иные процессоры переключают стек при переходе из режима пользователя в режим ядра. Вызов функции yield и фактическое переключение контекста происходит именно в режиме ядра. Эта мера действительно позволяет программисту в юзермоде вытворять со стекпойнтером всякую фигню. Но к теме статьи это не относится.
4. Ну и, насколько я помню, нигде в моей статье не написано, что «вытесняющая многозадачность эквивалентна вызову yield()». Она эквивалентна таймерному прерыванию+вызов yield().
1. Статья описывает реализацию в ядре. user mode в ней не затрагивается почти совсем.
2. Если вызов функции (yield — функция) портит стек, то компилятор надобно починить или заменить на исправный. Если стек портит реализация — её не надо было писать с ошибками. Если Вы её вызвали, а SP смотрит не на стек — ну, наверное, Вы погорячились.
3. Как Вы совершенно справедливо заметили (ну и, если Вы внимательно читали, у меня это написано сразу после примера кода «cpu_tss[ncpu].esp0 = (addr_t)t->kstack_top;») — Интеловские, да и все иные процессоры переключают стек при переходе из режима пользователя в режим ядра. Вызов функции yield и фактическое переключение контекста происходит именно в режиме ядра. Эта мера действительно позволяет программисту в юзермоде вытворять со стекпойнтером всякую фигню. Но к теме статьи это не относится.
4. Ну и, насколько я помню, нигде в моей статье не написано, что «вытесняющая многозадачность эквивалентна вызову yield()». Она эквивалентна таймерному прерыванию+вызов yield().
Если вызов функции портит стек, то компилятор надобно починить или заменить на исправный
Имеется ввиду затирание данных в памяти по адресам, меньшим SP
Если Вы её вызвали, а SP смотрит не на стек — ну, наверное, Вы погорячились
Может, мне регистров мало и esp я использую как дополнительный адресный регистр.
И вот тут yield неприменим…
Она эквивалентна таймерному прерыванию+вызов yield().
А вот тут соглашусь, использовать прерывание, чтобы получить стек для yield… Интересный взгляд на вытесняющую многозадачность.
Sign up to leave a comment.
Делаем мультизадачность