Файберы от тредов отличаются моделью многозадачности. Треды - вытесняющая модель, файберы - кооперативная.Сообщение от shurik-ua
Если строго, то в моём scheduler_g2 - гибрид тредов и файберов, модель там кооперативно-вытесняющая.Но по сути на ZX реально применимы только файберы - частота единственно имеющегося прерывания от таймера для вытесняющей модели крайне мала
Последний раз редактировалось Alex/AT; 15.07.2014 в 02:18.
Файберы (Fiber) - это нечто, похожее на потоки (Threads), но в некоторых ОС, таких как Win32, допускается исполнение (неодновременное) нескольких файберов в одном потоке. Отсюда происходит и термин. Thread - нить, а Fiber - волокно, т.е. боле мелкая, составляющая часть нити.
Каждый файбер имеет свой стек, как и поток. Но переключение между файберами происходит только вручную. Есть функция, например Win32 SwitchToFiber(HANDLE), которая переключает исполнение на заданный файбер. При этом состояние текущего файбера (стек) сохраняется. Когда другой файбер сам вызовет SwitchToFiber() на исходный файбер - то исполнение первого файбера будет продолжено.
Файберами нельзя полноценно заменить потоки. Однако меня долгое время интересовало, зачем они вообще нужны и что интересного можно сделать с их помощью. В комментариях на хабре как раз приведены ссылки. Основное применение и структура файберов обычно выглядит так:
... code ...
... call some_function ...
... code ...
При этом функция some_function где-то внутри себя вызывает SwitchToFiber, переключая исполнение на другой файбер, и когда другой файбер отдаст управление назад - функция some_function делает какие-то завершающие действия и возвращается.
Такая модель удобна, например, при проходе по файлу, организованному блочно, например .avi-файлу, где блоки звука перемежаются с блоками видео. Тогда можно сделать два файбера, один из которых обрабатывал бы только звук, а другой - только видео. В функции some_function следует разместить код чтения из входного файла, и в случае нахождения блока, принадлежащего "чужому" файберу - переключить исполнение на него.
---------- Post added at 19:19 ---------- Previous post was at 19:05 ----------
Спасибо, я поизучаю твой проект. Не знал о его существовании. Ну и в любом случае я делал бы свой, т.к. хотелось поупражняться в этом деле
---------- Post added at 19:24 ---------- Previous post was at 19:19 ----------
С этим согласен полностью.
А вот с этим категорически не согласен. При чем тут вообще прерывания от таймера к модели многозадачности? Вытесняющую многозадачность можно реализовать и вовсе без прерываний. Я думаю, дело в том, что многие заблуждаются насчет вытесняющей многозадачности в том, что будто бы ее основная идея - быстрое переключение между потоками (Round Robin), чтобы обеспечить их псевдопараллельное исполнение. Нет, на самом деле это тоже можно сделать, но вытесняющая многозадачность - это более широкое понятие, чем Round-Robin.Но по сути на ZX реально применимы только файберы - частота единственно имеющегося прерывания от таймера для вытесняющей модели крайне мала
В том диспетчере, который я опубликовал, вообще отсутствует упомянутое переключение по таймеру. Мои потоки переключаются только тогда, когда происходят события, требующие переключения потоков. Эти события могут происходить и по таймеру, и генерироваться внутри потоков, поэтому переключения потоков могут происходить как чаще, чем частота прерываний, так и реже. И вообще, чем реже - тем лучше, т.к. на переключение расходуется процессорное время.
Извини, но это бред. Для принудительного вытеснения задачи нужен инициатор переключения контекста. Без фонового инициатора вытеснения возможна только кооперативная многозадачность. Даже если мы будем "вытеснять" задачу сами в пределах ядра при вызовах функций ядра - всё равно это будет де факто кооперативная многозадачность, просто кооперативность будет обеспечиваться ядром, как частью задачи, и в контексте задачи.Вытесняющую многозадачность можно реализовать и вовсе без прерываний.
Простой пример: что будет, если задача не вызовет ни одну функцию ядра, вызывающую "вытеснение"? Тогда - либо прерывание (таймер) и вытеснение есть, либо вытеснения нет, и имеем чистую кооперативную модель.
Конечно, сделать вытесняющую многозадачность можно и с вытеснением раз в 1/50 секунды, но смысла в этом большого реально нет. Основное применение шедулера на ZX, как мне видится, это возможность в фоне считать "длинные" и вспомогательные задачи, параллельно исполняя основные, которые отрисовывают результат.
Я взял немножко другую модель - каждый поток может либо сам отдать время исполнения, т.е. чистая кооперативность, либо быть вытесненным по таймеру, если оное для потока разрешено. Никто, опять же, не мешает запихать принудительную кооперативность в некие системные вызовы ядра - и получим примерно то, что сделано в твоём планировщике - задача в принципе не узнает, что её время было отдано. Но это несколько плохо для синхронизации.Мои потоки переключаются только тогда, когда происходят события, требующие переключения потоков.
Почему настоятельно советую попробовать взять мой планировщик - собственно по двум причинам: а) он сильно оптимизирован; б) он умеет то, что жизненно необходимо ZX - хотя бы приблизительную синхронизацию с экраном. При условии, конечно, что задачи сообщают адекватное время выполнения в кооперативной модели. Как это работает - можно посмотреть в примерах. Он под GPLv2, поэтому можно смело выкладывать в GIT, если будут идеи - я присоединюсь к доработке, времени 100% мейнтейнить, к сожалению, нет. Да, код самого планировщика получился к сожалению достаточно сложным, оптимизация требует жертв. Там очень много комментариев, которые помогут разобраться.
Последний раз редактировалось Alex/AT; 15.07.2014 в 21:49.
Прошу заметить, я тебя не оскорблял.
Извини, но это неверно (в надежде на то, что дискуссию удастся вернуть в предметное русло, не буду употреблять по отношению к твоим словам оскорбительное слово "бред"). Вытесняющая многозадачность отличается от кооперативной тем, что решение о смене контекста принимается не задачей, а диспетчером. Википедию хотя бы почитай. "Фоновый инициатор вытеснения" - это возможность, но не необходимость.
Несмотря на то, что без вытеснения по прерываниям работа системы будет в некоторой степени детерминированной (наподобие кооперативной многозадачности), отсутствие знаний о работе хотя бы одного из потоков превращает работу такой системы в недетерминированную, когда каждый конкретный поток не знает, когда у него заберут процессорное время. Например, в моем диспетчере поток, устанавливая объект "Event", не знает, будет ли он при этом вытеснен. Это зависит от того, ожидает ли сигнализации этого объекта другой поток с более высоким приоритетом.
Ну и да, в моем диспетчере поддерживается вытеснение и по прерываниям, если в процедуре их обработки будут вызываться функции вида "SetEvent".
Ошибка именно здесь. Если обеспечивается ядром - значит уже не кооперативность.
Пойми, если в системе с безусловным и различным приоритетом потоков (как у меня) исполняется поток - значит он на этот момент времени имеет самый высокий приоритет в системе. Поэтому нет никаких оснований его вытеснять, по прерываниям или без них. И то, что он не будет вытеснен вплоть до того, как вызовет функцию ядра - это не признак кооперативной многозадачности, а ситуация при работе системы, когда не происходит событий, требующих смены контекста.
"Настоящие" современные ОС тоже не переключают контекст потоков без необходимости. Это дорогая операция. Зачем жечь время процессора зря? Даже переключение по таймслайсам для реализации Round-Robin псевдопараллельного исполнения использует интервалы времени, сравнимые или превышающие 1/50с.
В этом смысл многозадачности вообще, а не только на ZX. Длительная работа в режиме Round-Robin - это плохая ситуация даже на современных "больших" ОС, так как каждая задача при этом работает медленнее, чем хотелось бы.
Нет, получим не то, что сделано в моем планировщике, а Windows 3.11. Это там была "принудительная кооперативность" при вызове функции GetMessage или PeekMessage, а в других ситуациях контекст не переключался.
То, что сделано у меня - это переключение контекста по событиям, которые, по принятому принципу работы, являются основаниями для смены контекста. Быстро и максимально отдать время процессора приоритетным (важным) потокам; когда они чего-то ждут, например, нажатия клавиши - отдать время остальным.
Прерывания здесь важны, конечно, но и без них бы было примерно то же самое.
Точно так же сделано в реальных больших ОС. Я разрабатывал диспетчер после долгого и подробного курения исходников ReactOS (аналог Windows). Там, конечно, реализовано больше, чем у меня - но не в один день Москва строилась; и не все из этого нужно на ZX.
Хорошо, спасибо. Обязательно поизучаю!
ЕМНИП, частота вызова шедулера в том же linux может измеряться килогерцами. Как подсказывает Кэп и опыт, это хорошо сказывается на интерактивности системы, но крайне плохо на общей производительности.
Если обидел - извини, но сказанное противоречит собственно исходному определению вытесняющей многозадачности.Прошу заметить, я тебя не оскорблял.
Из фактического куда есть смысл смотреть: на ZX нет в целом смысла ждать прерывания для вытеснения потока - основное применение планировщика - распараллеливание действий типа отрисовки экрана, фонового обсчёта данных, обработки клавомыши, etc. А значит нормально подойдёт только кооперативная модель. Во многих демах и игрушках, кстати, можно найти свои суб-планировщики, и основная идея лично у меня была унифицировать подобный механизм так, чтобы практически любую процедуру можно было запихать под планировщик без принципиальных переделок. В том, что получилось - достаточно приблизительно посчитать такты, и расставить вызовы Slice/Idle.
Последний раз редактировалось Alex/AT; 16.07.2014 в 18:01.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Не следует путать частоту вызова планировщика с длительностью time slice. Потоки могут делать сколько угодно системных вызовов, и некоторые из них прямо или косвенно вызывают планировщик и приводят к смене контекста. time slice - это интервал переключения ядром потоков с одинаковым приоритетом в режиме Round-Robin при условии, что эти потоки не делают вызовов ядра, приводящих к перепланировке. Только что погуглил - в линуксе этот интервал составляет 100мс, а в винде - около 20мс, причем в случае винды серверная и клиентская версии используют разные значения. В серверной винде time slice дольше.
Интерактивность системы обеспечивается правильным распределением задач по потокам и правильным присвоением их приоритета. Если придерживаться правила иметь более высокий приоритет у потоков, осуществляющих взаимодействие с пользователем - то и получится высокая интерактивность. Помню, у нас в универе была машина на RSX-11 с терминалами. Один комп на 15 студентов. Бывало, человек 10 одновременно запускало компиляцию. Компилировалось жутко медленно, минут по 5 даже для коротких программ. Но при этом редактор у всех работал без задержек. Потому что его приоритет был выше, чем у компилятора.
---------- Post added at 03:34 ---------- Previous post was at 03:26 ----------
Пожалуйста в студию определение со ссылкой на источник.
Чот попутал, да. Давненько не брал в руки шашек
А если не RR алгоритм, то там как?
RR-алгоритм применяется только когда в системе имеется несколько потоков с одинаковым приоритетом в состоянии готовности.
Если в состоянии готовности находятся потоки с разным приоритетом - то процессорное время получает тот из них (один), который имеет высший приоритет. Остальные не получают процессорного времени до тех пор, пока поток с высшим приоритетом не перейдет в состояние ожидания.
Вот цитата из MSDN, Windows SDK
"Threads are scheduled to run based on their scheduling priority. Each thread is assigned a scheduling priority. The priority levels range from zero (lowest priority) to 31 (highest priority). Only the zero-page thread can have a priority of zero. (The zero-page thread is a system thread responsible for zeroing any free pages when there are no other threads that need to run.)
The system treats all threads with the same priority as equal. The system assigns time slices in a round-robin fashion to all threads with the highest priority. If none of these threads are ready to run, the system assigns time slices in a round-robin fashion to all threads with the next highest priority. If a higher-priority thread becomes available to run, the system ceases to execute the lower-priority thread (without allowing it to finish using its time slice), and assigns a full time slice to the higher-priority thread. For more information, see Context Switches."
Может. Но стандартный системный таймер - 10мс, что как бы 100Гц. Оттуда вызывется планировщик.
Кроме того - он вызывается из системных вызовов. Ну, скажем, вызвал ты select() или блокирующий read() - если данных нет, то управление будет отдано другим задачам-потокам.
"хорошо сказывается на интерактивности системы" то, что для всяких мышек есть аппаратное прерывание.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
