Делаем мультизадачность

[AngelOfSnow]

Прям глаз режет этот ваш «Шедулер», кто не работал с какой либо ОС вплотную, не поймут, что вы говорите о Планировщике (scheduler).

[dzavalishin]

Спасибо. :) Теперь, дочитав до Вашего комментария, поймут все. :)

[QtRoS]

А по мне довольно устоявшееся понятие, ни секунды не задумывался, о чем речь. И я бы не сказал, что ОС я вплотную занимался, так, общие знания, Танненбаум, как у всех :)

[NickViz]

угу, и «преемптивность» — есть же нормальный термин — вытесняющая многозадачность…

[dzavalishin]

Знаете анекдот? Оживили Сталина. Он очнулся, поглядел и говорит:
— Давайте расстреляем всех министров и покрасим Кремль в зелёный цвет.
— А Кремль зачем красить?
— Я рад, что по первому вопросу возражений нет.

:)

Я вот инверсию приоритетов не описал, вот что жалко… ладно, наверное, напишу про Планировщик при случае, там и отмечу.

[abondarev]

Конечно можно было продолжить комментировать названия:), но…
Разве нельзя сделать сигнатуру функции переключение контекста без третьего аргумента, я имею в виду спинлок. Ведь это проще сделать в вызывающей функции?

[dzavalishin]

Да, Вы знаете, я тоже это подумал, когда писал статью. Историческое наслоение.

[dzugaru]

Пожалуйста, не переводите threads как нити, в русских переводах есть устоявшийся термин «потоки».

[erlyvideo]

нити — это как раз очень правильный и удобный перевод.

Потоков много разных, особенно если дело доходит до какого-нибудь с++, а нити — сразу понятно, о чём речь.

[shabanovd]

Для меня оба термина странны, так что если не код то веще ничего не понял бы =)

[bormotov]

не то, что бы я прям вот много такого читаю по-русски, но мы между собой нити называем нитями. Хотя, сейчас всё больше акторы, но всё равно, когда какие-то разборки в глубь, то так и говорим «какой там шедулер у этого класса акторов, дефолтный? и им кадому по нити jvm дает, или кучу на одну вешает?»

[napa3um]

Тогда возникнет проблема в термине «streams».

[gena_glot]

А может попробовать 2-steps scheduler:
1. Select process.
2. Select thread

[dzavalishin]

А Вы какую задачу решаете?

[qw1]

Вытесняющая многозадачность не эквивалентна вызову yield()
Потому что вызов попортит стек. В актуальных ОС стек можно поставить в середину данных и крутиться в юзермодном спинлоке (потом esp вернуть обратно) и никакое вытеснение не испортит эти данные. Intel даже ввела специальный механизм, чтобы при получении прерывания стек перемещался в kernel space и юзер стек не портился.

[dzavalishin]

Мне кажется, Вы немного смешиваете разные вещи.

1. Статья описывает реализацию в ядре. user mode в ней не затрагивается почти совсем.

2. Если вызов функции (yield — функция) портит стек, то компилятор надобно починить или заменить на исправный. Если стек портит реализация — её не надо было писать с ошибками. Если Вы её вызвали, а SP смотрит не на стек — ну, наверное, Вы погорячились.

3. Как Вы совершенно справедливо заметили (ну и, если Вы внимательно читали, у меня это написано сразу после примера кода «cpu_tss[ncpu].esp0 = (addr_t)t->kstack_top;») — Интеловские, да и все иные процессоры переключают стек при переходе из режима пользователя в режим ядра. Вызов функции yield и фактическое переключение контекста происходит именно в режиме ядра. Эта мера действительно позволяет программисту в юзермоде вытворять со стекпойнтером всякую фигню. Но к теме статьи это не относится.

4. Ну и, насколько я помню, нигде в моей статье не написано, что «вытесняющая многозадачность эквивалентна вызову yield()». Она эквивалентна таймерному прерыванию+вызов yield().

[qw1]

Если вызов функции портит стек, то компилятор надобно починить или заменить на исправный

Имеется ввиду затирание данных в памяти по адресам, меньшим SP

Если Вы её вызвали, а SP смотрит не на стек — ну, наверное, Вы погорячились

Может, мне регистров мало и esp я использую как дополнительный адресный регистр.
И вот тут yield неприменим…

Она эквивалентна таймерному прерыванию+вызов yield().

А вот тут соглашусь, использовать прерывание, чтобы получить стек для yield… Интересный взгляд на вытесняющую многозадачность.