Разгрузка CPU в потоке

Цитата JoeUser @ 12.03.20, 15:47

Ну "захватил ты ресурс" (начал обрабатывать прерываание) , а если системный планировщик потоков вдруг задумает тебя задинамить на 10 сек? Владелец ты, или нет ... будешь висеть 10 сек на ожидании

Каким образом он это сделает, если обработчик еще не отослал EOI?

Добавлено 12.03.20, 16:05
Если мысль не понятна, то поясню. Текущий поток, который исполняется на ядре может переключиться только 2 сценариями:
1. поток добровольно отдает управление: по сути это все блокирующие функции.
2. происходит аппаратное прерывание и ОС принудительно делает переключение.

Сообщение отредактировано: shm - 12.03.20, 16:06

shm, на все вопросы отвечать не буду, хлопотно это цитировать вики

Но замечу ... давай определимся о какой "многозадачности мы говорим? из
общеупотребимых - "кооперативная" и "вытесняющая". В первом случае (а это
ранние версии Венды - поток сам решает, что и когда ему "отдавать". Во
втором - ядро решает:

Цитата

В реализации вытесняющая многозадачность отличается от кооперативной, в частности, тем, что требует обработки системного прерывания от аппаратного таймера. По истечении кванта времени, отведённого процессу, происходит прерывание и вызывается планировщик процессов. Частота вызова планировщика критична: слишком частый его вызов будет расходовать процессорное время впустую.

Цитата shm @ 12.03.20, 16:03

поток добровольно отдает управление

??? Это где и когда поток управлял своим выполнением ??? А системный планировщик потоков был всегда "свадебным генералом"???

Резюме

Кто-то из нас не имеет должных знаний, или не имеет тупо чуйки.
Допускаю, что я. А ты?

JoeUser, на венде всё просто: любой пользовательский код работает на уровне приоритета ниже, чем у ... э-эм, "синхропроцесса", что и позволяет последнему указывать шедулеру, какой из потоков должен спать на объекте, а кто работать; синхропроцесс работает на максимальном "программном" уровне приоритета; все прерывания работают на уровнях выше "программного". Очень грубо, но даёт представление о взаимодействии приоритетов, объектов синхронизации и шедулера. Важный вывод: объекты синхронизации не могут использоваться обработчиками прерываний, т.к. у них приоритеты выше, чем те, которыми способен управлять "синхропроцесс". Так что как ни старайся, в лучшем случае WaitForXXXX() просто вернёт управление назад безусловно и безотносительно.

Цитата Qraizer @ 12.03.20, 16:58

oeUser, на венде всё просто: любой пользовательский код работает на уровне приоритета ниже, чем у ... э-эм, "синхропроцесса"

Вангую, даже нет!!! Вещяю аки Соловьёв на TV - не только в венде, везде так. Иначе был бы аут и песец.

Цитата Qraizer @ 12.03.20, 16:58

все прерывания работают на уровнях выше "программного"

Не в курсе, не знаю, но я бы вынес этот обработчик в kernel-space. А уж из него в usеr-program слал результаты (а лучше - ивенты).

Цитата Qraizer @ 12.03.20, 16:58

Важный вывод: объекты синхронизации не могут использоваться обработчиками прерываний

Я-я ... гер майор - вся "аппаратура должна оседать в кернель моде". Это - справедливо!

Цитата JoeUser @ 12.03.20, 15:47

Цитата shm @ 12.03.20, 15:40

И что тебе это даст?

Временное примирение с Килей!

Знаешь, чтобы решать такие задачи, надо приобретать
базовые знания. На лекциях в ВУЗ-е, читая книги,
разыскивая статьи и доки - самостоятельно.
---
Конференция - это как курилка. Где можно услышать
интересную мысль, узнать перспективный программный приём.
А можно и не услышать и не узнать.
Образования так не получишь.
---
Книга - друг инженера.

Цитата JoeUser @ 12.03.20, 16:34

из
общеупотребимых - "кооперативная" и "вытесняющая". В первом случае (а это
ранние версии Венды - поток сам решает, что и когда ему "отдавать". Во
втором - ядро решает:

Почти во всех современных ОС многозадачность гибридная, т.е. обычно потоки отдают управление самостоятельно, но ОС может забрать управление по таймеру, если поток превысил допустимый квант времени.

Цитата JoeUser @ 12.03.20, 16:34

??? Это где и когда поток управлял своим выполнением ???

Любые блокирующие функции к этому приводят. Доказать могу легко: делаешь Sleep(N) - в это время загрузка потока будет 0, аналогично чтение файла и пр... Поток может добровольно отдать управление, гарантированно получить управление он не может.

Цитата JoeUser @ 12.03.20, 16:34

А системный планировщик потоков был всегда "свадебным генералом"???

Я не понимаю о чем ты.

Цитата JoeUser @ 12.03.20, 16:34

Кто-то из нас не имеет должных знаний, или не имеет тупо чуйки.
Допускаю, что я. А ты?

У меня есть свое игрушечное мини-ядро ОС с поддержкой SMP. Это так, для общей информации. Об ядрах *nix и Win тоже знаю представление и рекомендую посмотреть исходники ReactOS.

Добавлено 15.03.20, 12:51

Цитата JoeUser @ 12.03.20, 17:10

Не в курсе, не знаю, но я бы вынес этот обработчик в kernel-space. А уж из него в usеr-program слал результаты (а лучше - ивенты).

kernel-space != уровень приоритета

Цитата JoeUser @ 12.03.20, 17:10

Я-я ... гер майор - вся "аппаратура должна оседать в кернель моде". Это - справедливо!

Разработчики микроядерных ОС с тобой несогласны.

Сообщение отредактировано: shm - 15.03.20, 12:51

Цитата shm @ 15.03.20, 12:47

Разработчики микроядерных ОС с тобой несогласны.

Просто они хотрованы! Когда нормальные пацанчики разделяют "kernel-mode" и "usеr-mode", то они лепят еще один слой, и получается "kernel-mode"
, "service-mode" и "usеr-mode". И в "service-mode" типа работает весь фарш. Ну давайте не будем кривить душой - откусили часть функционала ядра, обособили, снабдили большим чем юзер-спейс и меньшим чем кернель-спейс (возможно планировщик ядра повесили сверху). Ну да, может стало отзывчивее ... НО ОТ ЭТОГО АППАРАТУРА НА СТОРОНЕ ЮЗЕРА НЕ СТАЛА ОБРАБАТЫВАТЬСЯ! В загружаемых модулях, в "забытых детях ядра"

Цитата JoeUser @ 15.03.20, 14:18

Когда нормальные пацанчики разделяют "kernel-mode" и "usеr-mode", то они лепят еще один слой, и получается "kernel-mode"
, "service-mode" и "usеr-mode".

Бывают и всего с 2 слоями.

Цитата JoeUser @ 15.03.20, 14:18

Ну давайте не будем кривить душой - откусили часть функционала ядра, обособили, снабдили большим чем юзер-спейс и меньшим чем кернель-спейс (возможно планировщик ядра повесили сверху). Ну да, может стало отзывчивее ... НО ОТ ЭТОГО АППАРАТУРА НА СТОРОНЕ ЮЗЕРА НЕ СТАЛА ОБРАБАТЫВАТЬСЯ! В загружаемых модулях, в "забытых детях ядра"

Микроядерные ОС не отзывчивее монолитных. Там фишка в другом - они (в теории) стабильнее и безопаснее. И да, в некоторый микроядерных ОС прерывания обрабатываются в user-space.

Цитата JoeUser @ 15.03.20, 14:18

НО ОТ ЭТОГО АППАРАТУРА НА СТОРОНЕ ЮЗЕРА НЕ СТАЛА ОБРАБАТЫВАТЬСЯ!

Давно уже можно на стороне юзера обрабатывать теже сетевые пакеты минуя стек ОС полностью

Цитата Gonarh @ 16.03.20, 23:07

Давно уже можно на стороне юзера обрабатывать теже сетевые пакеты минуя стек ОС полностью

Но это вот не значит же, что это программа напрямую общается с аппаратурой сетевого контроллера? Если речь идет о сырых сокетах, так то через API операционных систем.

Цитата JoeUser @ 17.03.20, 03:08

Но это вот не значит же, что это программа напрямую общается с аппаратурой сетевого контроллера?

Ну драйвер конечно нужен, НО, только для инициализации железки и предоставление интерфейса. Затем делается анбинд сетевухи, чтобы ОСь не дёргалась на неё вообще. Я попробовал туда сунуться, хотел по минимуму сетевой стек нарисовать, хотя бы базовое типа arp/ip, обычная маршрутизация трафика, но не хватает мозгов, лазию читаю, облизываюсь.

Сообщение отредактировано: Gonarh - 17.03.20, 04:16

Цитата Gonarh @ 17.03.20, 03:56

Ну драйвер конечно нужен,

Вот поэтому и говорим, что драйвер дает только API для управления "железом". Хотя, я как-то встречал интересный драйвер уровня ядра для винды, что-то типа portio.sys (не помню точно). Цель создания этой дровины - дать доступ из режима пользователя к портам железа. Да, и драйвер был, и проги были, его использующие. Но это все равно "хак", а не нормальное программирование. Зачем создавать и отлаживать защищенные механизмы Оси, если вот такие дыры в ней проделывают?

Цитата JoeUser @ 17.03.20, 04:31

Зачем создавать и отлаживать защищенные механизмы Оси, если вот такие дыры в ней проделывают?

Затем, что если убрать обработку сетевого пакета тем же линухом, и обработать его самому, то время обработки сократиться до ~60 циклов CPU на пакет, вот и посчитай какие хайлоад системы по обработке сетевого трафика можно реализовать, сиськи с джуниперами нервно курят в сторонке.

Сообщение отредактировано: Gonarh - 17.03.20, 08:09

Цитата Gonarh @ 17.03.20, 08:07

Затем, что если убрать обработку сетевого пакета тем же линухом, и обработать его самому, то время обработки сократиться до ~60 циклов CPU на пакет, вот и посчитай какие хайлоад системы по обработке сетевого трафика можно реализовать, сиськи с джуниперами нервно курят в сторонке.

И все равно я не согласен. Не хочешь отдавать пакеты родному стеку - напиши свой загружаемый модуль и в нем обрабатывай. С точки зрения защищенности системы - это, правильнее ИМХО.

ЗЫ: Хотя мы, походу, уходим куда-то в сторону от темы топика