Операционная система. Плоды размышления

[ARV]

Мама родная.... Ребят, я всю тему два раза прочитал, но так и не смог понять, О ЧЕМ же вы спорите? С чего спор начался? Кто что утверждает?

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

[Пухич]

если вспомнить упоминание о быстроте реакции - то я настаивал и настаиваю, что АСИНХРОННАЯ обработка требуется как раз для случаев, когда эта самая скорость необходима. не улавливаете, Yellow Tiger, что это не совсем то, что говорите вы и что хотите мне приписать? вы же уверены, что так обрабатывать правильно любые события, даже те, которые могут и подождать.

Это верно. О чем же дальше спорить? Иногда прерывания просто необходимы (если событие наступит неизвестно когда и проверка отнимает много времени). А иногда можно и циклом опрашивать - если проверка недолга и событие гарантированно скоро произойдет.

Момент быстрого ответа на событие тут совсем не катит. Далеко не всегда использование прерываний дает наибыстрейшую реакцию - проблема длительного сохранения контента уже давно обсуждается. Вплоть до возврата к старому доброму 8085 (я про Sojourner).

[ARV]

вы сами-то понимаете, что сейчас сказали?

Я-то да, а вот сделать так, чтобы вы меня поняли, мне не удается - я вам говорю, оставьте точку зрения "изнутри" одной только программы, а вы упорно рассуждаете с тех же самых позиций. Что ж, привычная точка зрения может иногда казаться единственно возможной.

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

перехватывая прерывание таймера...

Думаю, вы и сами понимаете, что называть это вытесняющей многозадачностью - перебор. На 8086-ом любая программа может взять таймер на себя и если она после это зависнет, управление больше никогда не вернется...

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

да, кстати, а как по-вашему, реализована вытесняющая многозадачность в той же Винде? я приотстал от прогресса - может в ядре процессора появились какие-то возможности без прерываний, чисто аппаратно переключаться между процессами? т.е. без единой команды ассемблера - настроил проц на определенные интервалы переключений, и все? по-моему, этого нет... хотя я могу ошибаться... чисто логически: если бы так было - ОС невозможно было бы завесить в принципе... ядро бы все едино работало бы...
по-моему, и сейчас переключение задач ОС производит по таймеру, просто она 100% не дает никому перехватить это дело... но чисто теоретически такая возможность (я про перехват) все равно существует

[Yellow Tiger]

для прикладного программиста существует только один
взгляд - изнутри программы

Не согласен. И даже удивлен тому, что слышу это от вас - вы же думаете об устройстве в целом, когда проектируете его. Да и локальная задача (уж такова реальность) порой вовсе нерешабельна, если не знать разных тонкостей (а порой - списка багов) той исполняющей системы, под которую предназначен результат работы прикладного программиста.

и сейчас переключение задач ОС производит по таймеру, просто она 100% не дает никому перехватить это дело...

Ну, так а как вы думаете - зачем я сначала спросил, на каком процессоре вы создавали свою систему? Ага, именно за этим...

Все, я - спать!

[UA3MQJ]

Касательно микроконтроллеров нас учили так:

В основном цикле программы выполняются все процедуры (естественно последовательно), например чтение клавиатуры, вывод на экран.

Каждая процедура этого уровня не должна выполняться слижком долго. Как например чтение с клавиатуры с учетом дребезга. Использование цикла считалось не правильным, т.к. это вешало систему. Предлогалось использовать счетчики и в каждой итерации цикла их менять и принимать решения о результатах каких-то.

Хотя я тогда хорошо поспорил со своим преподавателем на тему обработки нажания в цикле процедуры или в общем цикле. Что мол в ТЗ не указана эта особенность реализации и, так как других функций устройство не выполняло, реализация цикла внутри процедуры никак не влияло на работу устройства. Внешне все выглядело так же.

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

Когда же требовалось реализовать что-то точно, например часы/секундомер/таймер, то пришлось реализовать внешний таймер и работу по прерываниям.

-----------------------------------

Касательно беседы уважаемых Тайгера и ARV. Наверное зря все ушли в сравнения на базе реализаций ОС.

Как-то формулировки ARV мной проще воспринимаются. И получается, что только DOS нормально работала, т.к. она работала по прерываниям. Но и там работающая программа не сразу реагировала на события. Достаточно вспомнить, например, обработку клавиатуры:
(пишу на паскале, но всем и так будет понятно)

Код: Выделить всё

var c:char;
...
repeat
  if keypressed then begin
    c:=readkey();
    if c=#00 then c:=readkey();
    {а дальше обработка разных кнопок}
    if c="1" then {и так далее}; 
    if c="2" then {и так далее}; 
    if c="3" then {и так далее}; 
  end;
until c=#27 ; {выход, если esc}

То есть основной напоминает что-то нам до боли знакомое в основном цикле обработки событий...

Но зато была возможность, при работе с портами (например), написать свой обработчик прерывания и быть уверенным, что он выполнится практически сразу.

-----------------------------------

По поводу ОС. Раз уж пошла такая пьянка, в целях повышения образованности. Расскажите мне что такое многозадачность/многопоточность в винде при том, что аппаратно процессор может реализовывать только переключение процессов, т. е. только многозадачность. Упомяну еще то, что в unix многопоточности нет. А система реального времени QNX все равно не является системой реального времени, а тольго обещает что-то сделать в течении "не больше определенного промежутка времени"... ушел в размышления.

[ARV]

И даже удивлен тому, что слышу это от вас - вы же думаете об устройстве в целом, когда проектируете его. Да и локальная задача (уж такова реальность) порой вовсе нерешабельна, если не знать разных тонкостей (а порой - списка багов) той исполняющей системы, под которую предназначен результат работы прикладного программиста.

давайте отделим мух от котлет.

либо мы говорим об устройствах на МК, где в помине нет ОС (уточняю - простых 8-битных МК), и тогда связь программы с устройством вцелом очевидна, либо мы говорим о каких-то программах, исполняющихся в многозадачной ОС типа Windows, и тогда связь программы с железом вовсе не очевидна, если не сказать отсутствует в прямом смысле слова.

в первом случае рассуждения о синхронности и асинхронности так или иначе сводятся к обработке аппаратных прерываний, и все, что я по этому поводу думаю, я уже сказал. но могу повторить, резюмируя:
- обработка внешних событий принципиально АСИНХРОННО должна осуществляться только в случаях, когда требуется немедленная реакция на событьие. как правило, эта обработка осуществляется полностью в обработчике прерываний.
- в случаях, когда такая "резвость" не требуется - обработка может вестись как АСИНХРОННО (по прерываниям), так и СИНХРОННО (т.е. по опросу). С моей точки зрения второй способ более прост и рационален.
- введение АСИНХРОННОГО ПРИЕМА события с ОТЛОЖЕННОЙ обработкой - тоже вариант, наверное, выгодный порой. хотя простоты реализации тут нет. Именно этот способ, как я догадываюсь, вы и имели ввиду, говоря об обработке злосчастных кнопок: приняли немедленно событие, установили какие-флаги, а потом в основном цикле обнаружили изменение этих флагов и предприняли какие-то действия. С моей точки зрения этот гибрид лишь прибавляет сложности в решении, не увеличивая ни скорость реакции, ни какие либо еще принципиальные характеристики программы.

во втором случае восприятие программы узким взглядом программиста-прикладника - вполне обосновано и разумно. Ориентация на особенности ОС и тем более на какие-то ее глюки - это абсурд, нонсенс и вообще ни в какие ворота! Это тупиковый путь, ставящий под сомнение переносимость и универсальность кода. Языки высокого уровня, принципиальное понятие операционной системы созданы именно с целью отделить программу от среды исполнения, программиста от аппаратуры. Пытаться выдать подход, который все это отрицает, за единственно верный - с моей точки зрения опрометчиво и даже недопустимо. В этом случае идеальной была бы ситуация, когда программист вообще ничего не знает об ОС, кроме интерфейса API, и как я могу наблюдать - к этому постепенно и идет: Java и .Net тому неплохое подтверждение.

Так что не могу согласиться ни с одним вашим утверждением.
Если вы согласны со мной - скажите об этом; если не согласны - укажите на это и подтвердите свою т.з. примерами, чтобы я наконец, понял, в чем же я заблуждаюсь.

И хотелось бы получить ответы от вас на заданные ранее вопросы о том, как функционирует многозадачность в Windiows, образцы программ, подтверждающих вашу точку зрения или опровергающих мою, и т.п. "моменты", с которыми я к вам обращался

И в довесок: я так и не понял из ваших слов - как именно сейчас реализуется переключение задач в Windows и других ОС: по таймеру или нет? Я действительно не знаю точно, лишь предполагаю, что по таймеру.

[ARV]

По поводу ОС. Раз уж пошла такая пьянка, в целях повышения образованности. Расскажите мне что такое многозадачность/многопоточность в винде при том, что аппаратно процессор может реализовывать только переключение процессов, т. е. только многозадачность. Упомяну еще то, что в unix многопоточности нет. А система реального времени QNX все равно не является системой реального времени, а тольго обещает что-то сделать в течении "не больше определенного промежутка времени"... ушел в размышления.

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

на счет потоков и задач, которых много. поток - это как бы отдельный цикл, который может выполняться сам по себе - он является неотъемлемой частью задачи, но (чисто абстрактно) исполняется параллельно с нею. т.е. поток - это как бы задача, порожденная самой задачей... может, пример более поможет понять: предположим, нам хочется одновременно расчитывать какую-то систему диф.уравнений и при этом рисовать на экране картинки. мы можем поступить так: в цикле расчетов сделать 100 итераций, потом нарисовать кадр картинки, потом еще 100 итераций - и снова кадр... внешне все будет выглядеть, как одновременное... это пример одного потока для одной задачи. теперь иной способ: мы оформляем цикл расчетов, как отдельный поток, и запускаем его. теперь о том, чтобы и расчет и основной цикл программы (в котором теперь только рисование) выполнялись параллельно, будет операционная система - это она будет по чуть-чуть поочереди выделять времени и потоку расчета и главному циклу проги... и все снова будет как бы одновременно...
Самое интересное, что этот способ не так уж и прост, как кажется... Например, может оказаться, что благодаря выносу расчета из цикла рисования кадров, мы получим ускоренную их отрисовку! а может быть и наоборот - замедленную... т.е. в любом случае придется привязывать частоту кадров к таймеру (в принципе, и в первом случае так следовало бы поступать). Второй нюанс - надо уведомить основной цикл о том, что расчеты в другом потоке закончились, иначе система автоматически убъет (может убить) поток, как только его цикл завершится, и мы не получим расчета... Третий нюанс: если надо изменить параметры расчета в ходе расчета, или узнать промежуточные его результаты - нам надо как-то синхронизироваться с потоком, т.к. раз он выполняется параллельно и независимо, основная программа никогда не может знать точно, что та или иная переменная этого потока (они доступны) действительно содержит верные значения... Ну и т.п. Зато мы имеем возможность указать приоритет потока, т.е. указать системе, как много времени на исполнение потока надо выделять ему по сравнению с другими потоками, имеющимися в системе... Задав приоритет "реального времени" мы запросто можем настолько затормозить как саму ОС, так и прочие программы, что это будет больше похоже на зависание... Задав приоритет "только в простое" мы можем добиться того, что наш поток практически никогда не получит управления, т.к. будет ждать момента, когда никакая задача ничего не делает. т.е. ОС простаивает (что на практике хоть бывает и часто, но по гигагерцовым меркам равносильно полному отсутствию работы).

я привел упрощенное объяснение потока и задачи, но оно не противоречит принципиально "официальному", для понимания достаточно.

думаю, что в юниксе обязательно должна быть поддержка потоков - возможно они называются иначе, нитями (Thread), например... поток - это руский термин, его перевод Stream далеко не всегда обозначает то, что мы тут подразумеваем... иноземцы часто используют термин Нить для этого.... в общем, полный бардак

[UA3MQJ]

Спасибо за объяснение. Я в курсе различий между нитями и процессами. Иногда их еще вроде называют легковесными процессами.

Для себя я такую аналогию ввожу:
процесс - вся программа целиком;
поток - запуск параллельно с основным руслом программы какой либо её процедуры.

Именн возможностью запуска в фоне некоторых процедур мне и понравилась ява. Там это, как бы, на уровне самого языка реализовано.



Я хотел спросить именно как это реализуется аппаратно, ведь процессор переключает именно целые процессы.

[SergeBS]

По поводу ОС. Раз уж пошла такая пьянка, в целях повышения образованности. Расскажите мне что такое многозадачность/многопоточность в винде при том, что аппаратно процессор может реализовывать только переключение процессов, т. е. только многозадачность. Упомяну еще то, что в unix многопоточности нет. А система реального времени QNX все равно не является системой реального времени, а тольго обещает что-то сделать в течении "не больше определенного промежутка времени"... ушел в размышления.

Сначала задам всего 1 вопрос: откуда дровишки про unix?
И намекну: основополагающими объектами unix от рождения были каналы, ПОТОКИ и процессы. Что и того и другого и третьего много надо - объяснять почему?
При этом аналогом виндовых задач являются не потоки, а процессы. Это так сказать, уточнение.
Насчет аппаратного переключения процессов - ну загнул.
Аппаратно процессор может отрабатывать прерывания. И только. Все остальное - как фишка ляжет , т.е. программа велит. В том числе и обработка прерываний.
Программу обзываем по вкусу:QNX, Unix, Windows, DOS.
Вааще коды с дискеты загружу и ни на что кроме клавиатуры реагировать не буду. И то только на 1 кнопку. ВОЛШЕБНУЮ (RESET не на всех системниках есть!)

Дальше. По теме спора. Вы гг. спорящие вначале определитесь, для чего код пишете. Поскольку есть системы реального времени (RTOS), и есть прочие (кстати все Винды относятся к прочим). RTOS гарантирует отработку некого события за некий интервал времени (в смысле - не позднее чем этот интервал пройдет). По своему определению. Для разных событий могут быть разные интервалы.
Для RTOS без прерываний и приоритетов прерываний никуда.
Между прочим: система прерываний в архитектуре Intel принципиальных изменений не имела с самого первого их микропроцессора.
По теме Винды: вытесняющая многозадачность - это БЫЛО. В ХР и далее задача в зависимости от приоритета получает кванты времени (мал приоритет - мало квантов).
Это не называется вытесняющей многозадачностью.
Именно поэтому ХР завесить, как 95 не получается - у любой задачи квант кончится и заработает другая, а значит пресловутыми 3 пальцами вызываем диспетчер и убиваем зависший процесс. Только порой ждать надоест. И никакая задача не может получить прямой доступ к любому устройству (в том числе и таймеру) без грязных хакерских штучек. Принципиальное отличие линейки NT от линейки Win95.
Далее: линейка NT-XP с IBM имеет нечто общее: WinNT родилась как OS/3. А вот дальше их пути разошлись.
Сейчас главный идеолог линейки NT - инженер из почившей DEC, автор и идеолог RSX-11 (она же ОС РВ ежели по-русски). Оттуда кстати и хохма с расположением таблицы файлов.
Насчет повышения образованности: в 95 программа получала при запуске приоритет и в зависимости от него отдавала проц другой через какой-то интервал времени. Но могла и не отдать и завесить всю систему. Задачи вытесняли друг друга. Типа кто шире пальцы растопырит - тому и больше времени процессора достанется. В том числе и ВСЕ время. Захватил клавиатуру и крутись в бесконечном цикле - делов на 5 минут.
В NT любая запущенная задача в зависимости от приоритета получает кванты времени процессора. При этом ее выполнение прерывает ядро системы. Гарантированно. Ежели конечно не применять вышеупомянутые штучки.
При этом все что может задача - получить адресованное ей сообщение (из очереди сообщений) и его отработать. Если понимает это сообщение. А эту очередь организует опять же ядро системы.

Ну и соответственно коротко резюме: спорить-то не о чем.
Как работать - по прерываниям или без - зависит только от задачи. Ну в совсем простых случаях - от личных пристрастий. ИМХО.
Простой (и надеюсь наглядный) пример:
Пусть есть AtmegaXXX.
Если я меряю напряжение с помощью встроенного АЦП, задав ему делитель 128 - я легко успею его обслужить по прерываниям. Как правило. А вот если я задам делитель 2, то пока произойдет прерывание, да пока возврат из него - просто запихнуть померянное в память я уже не успею. И поэтому в этом случае, пока не намеряю сколько надо - все остальное пошлю подальше (запрещу прерывания) и буду втупую смотреть - готовы данные АЦП? Как готовы - в память их, и проверить - намеряли сколько надо или нет? Если намеряли - можно разрешать прерывания и дальше работать в других направлениях. Есс-но, если нет более важных задач, чем N, нет N маловато, возьмем M раз померять АЦП напряжение.

2Yellow Tiger:
Чуть не забыл: прикладной программист не обязан знать баги системы. Вместо этого он знает (если знает ) баги своей среды разработки. Если не веришь - попробуй найти в описании ОС список ее багов. Да вообще - увидишь BSD - запиши и попробуй найти объяснение ...

[ARV]

Насчет повышения образованности: в 95 программа получала при запуске приоритет и в зависимости от него отдавала проц другой через какой-то интервал времени. Но могла и не отдать и завесить всю систему. Задачи вытесняли друг друга. Типа кто шире пальцы растопырит - тому и больше времени процессора достанется. В том числе и ВСЕ время. Захватил клавиатуру и крутись в бесконечном цикле - делов на 5 минут.

небольшое уточнение: программа "отдавала" управление, когда обращалась к системной функции Windows API (не любой). Winda в этом случае сразу пыталсаь дать шанс другой задаче... т.е. опять же с точки зрения программы никакой отдачи управления не было - вызвали системную функцию, когда-нибудь она возвращала управление и все продолжалось... а то, что пока эта функция "вызывалась", система успевала обслужить еще кучу программ-потоков - это никто как бы не замечал. и именно этот принцип называется кооперативной многозадачностью, в отличие от вытесняющей, которая пошла со времен NT и далее: к сожалению, вы тут неверно трактуете термин... вытесняет не одна задача другую, а ОС вытесняет одну задачу другой... вставляя как бы клин между ними.
в чистом виде такая кооперация была только до появления 95-й: эта ОС уже предпринимала попытки не дать вредничать тем программам, которые не вызывали системные функции... но 95-я справлялась с этим делом плоховато...

в NT и XP сосуществуют оба подхода: переключение задач ведется и кооперативно (с учетом приоритетов), и принудительно (так же с учетом приоритетов). Для нитей или потоков понятие кооперации отсутствует...

[UA3MQJ]

Сначала задам всего 1 вопрос: откуда дровишки про unix?
И намекну: основополагающими объектами unix от рождения были каналы, ПОТОКИ и процессы. Что и того и другого и третьего много надо - объяснять почему?

Объясните почему.

Не помню. Слышал где-то...
Как на с++ в unix создать, соответственно? :
-канал
-поток
-процес

Просто я не давно си изучаю и поэтому кроме fork...

Хотя ладно. Че спрашивать. Интернет есть, посмотрю в нем.

[SfS]

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

Данное высказывание истинно, когда относится к СПОРАМ, а не к визгам новодвороподобных гуманитарных быдлодемшизоидов в дуроящике. К сожалению, в настоящее время слово "спор" стали употреблять и преминительно к ругани базарных бабок и к потугам тележурнашлюшек.

Если же "спор" понимать как "установление истины на основе имеющихся фактов" - то именно "в споре рождается истина". Если при этом один из спорящих имеет одно множество фактов, а другой - другое, то ничего удивительного, что они имеют разные точки зрения на один и тот же вопрос. И если спорщики выслушивают и пытаются понять точку зрения друг друга - часто это очень полезно для всех.

А "споры" уровня - "ты дурак нет ты дурак" - те да... Только там ни о какой истине в принципе речь не идёт.

[SfS]

А вообще прикольная тема Флеймогонная.
Я, правда, так толком и не понял - очём тут "размышление" было.
Если о способах организации многозадачек - то на то есть учебники.

Например (в инете есть):

"Операционные системы. Т.Б.Большаков - Д.В.Иртегов"
"Сетевые операционные системы. Н. А. Олифер, В. Г. Олифер"

Там всё разжевано как для деби.. ой ддя выпускников современных школ.

Если о том "как в венде работает многозадачность" - то ответ один "хреново". Потому что Виндовс - система, тащущая за собой столько старого хлама для поддержки приложений тысячелетней давности, что сделать, чтобы этот зоопарк работал хорошо - невозможно в принципе.

Если же хотите просто разобаться как организована многозадачность - то возьмите любую мелкую открытую ОС типа eCos или NedoPC-ARMOS и поройтесь в кодах. Всё увидите и пощупаете.

[Пухич]

Вот уж действительно - перешли с принципов обработки ВНЕШНИХ АППАРАТНЫХ событий к принципам построения многозадачности. Хотя это две совершенно разные вещи. Можно иметь любую комбинацию обработки (прерывания, опрос) и видов многозадачности (невытесняющая, вытесняющая). В чем же спор? Особенно в применении к AVR, где никакой многозадачности пока в общем-то нет.

"Операционные системы. Т.Б.Большаков - Д.В.Иртегов"

Кстати, превосходная вещь. Всем рекомендую. А вот Олиферов студенты наши сильно любят почему-то.

Задачи вытесняли друг друга

Ничего подобного. Задачи всегда вытесняются диспетчером ОСи.

[Yellow Tiger]

...я так и не понял из ваших слов - как именно сейчас реализуется переключение задач в Windows и других ОС: по таймеру или нет? Я действительно не знаю точно, лишь предполагаю, что по таймеру.

Этот вопрос не по адресу. Мои задачи не требуют знания того, каким именно способом реализуется переключение задач в винде - по таймеру, или нет, поэтому, как и Вы, я пользуюсь предположениями. Правда, я бы сделал более широкие предположения - кроме таймера, винда, в целях управления исполнением задач, наверняка пользуется обращением задач к ресурсам ОСи и (возможно) к ресурсам компьютера. Так, например, системный вызов GetMessage блокирует поток, если в его очереди нет сообщений - не исключаю, что это не единственный вызов, которым пользуется винда для управления потоками.

Теперь попробую другими словами объяснить то, что я имел ввиду, когда говорил об асинхронности исполнения кода, который с точки зрения самой задачи выглядит синхронным.
Как я уже говорил, мои рассуждения касаются реального порядка выполнения кода программы, то есть - с учетом того обстоятельства, что винда останавливает исполнение потока, когда в очереди событий пусто. Скажем, изображу это вот так:


Если смотреть только на текст программы (то есть, не учитывать того как она исполняется ОСью) то всё выглядит синхронным, но если не ограничиваться взглядом на программу "изнутри", а учитывать реальный порядок действий как программы, так и винды, то получается так:

Событие - реакция, ... событие - реация. Между событиями - никакой реакции, цикл while "спит", так как отлучен от процессора.
Я называю это асинхронным исполнением, вы, если это вам по какой-то причине очень нужно, можете называть синхронным.

А вообще прикольная тема Флеймогонная.

Да, каждый вопрос в ней стремится распасться на несколько новых, и потому об остальном - позже, если понадобится. Уж очень мало времени.

[Пухич]

если в его очереди нет сообщений

Что-то я совсем запутался. О каких сообщениях речь? Об очередях межпроцессных сообщений в Linux?

[ARV]

Yellow Tiger, хочу вас обрадовать и огорчить:
во-первых, вы абсолютно правы на счет того, что вызов системных функций используется виндой для переключения процессов, кстати, я об этом в одном из своих постов и говорил. но меня интересовал именно аппаратный способ, ну, я предполагал, что может быть в современных процах есть какой-то встроенный таймер, именно процессорный, "невидимый" для программ, который так же может инициировать переключение процессов... скорее всего, это я размечтался
во-вторых (и это огорчает) в вашей красивой картинке есть один изъян: что произойдет, если ни один из запущенных процессов не имеет в своей очереди сообщений? По-вашему выходит, что ОС в сущности усыпит все процессы... А по факту этого не происходит.

На самом деле винда поступает так (я исключу из рассмотрения аппаратно вызванное переключение процессов, т.е. по таймеру, и ограничусь именно "кооперативным"):
1. Обнаружив вызов GetMessage ОС проверяет, есть ли в очереди этой задачи сообщения. если есть - оно немедленно извлекается и передается программе на обработку.
2. Если очередь пуста - ОС начинает переключение процессов, т.е. пока все, как вы и говорили.
3. Когда все процессы просмотрены, происходит возврат из той самой getMessage с кодом "очередь пуста" и программа отрабатывает ситуацию IDLE - т.е. простой.

Отсюда налицо нарушение вашего красивого алгоритма - событие--> реакция, и все превращается в то, с чего я и начал разговор: опрос и реакция. Хотя, вы, конечно, можете вывернуться, назвав отсутствие событий так же событием, что с точки зрения программиста действительно так... Но в таком контексте наша беседа превращается в спор "что было раньше - курица или яйцо?", т.е. "сначала собыите а потом реакция или сначала запрос события, а потом реакция"... т.е. абсолютно бесперспективный спор...

[Пухич]

Опять двадцать пять. О каких событиях/сообщениях речь?

Сколько ни писал прог, никаких GetMessage-й не вызывал. Шо це такэ?

[ARV]

Пухич, чтобы было проще писать программы, и мелкософт, и другие господа понаделали всяких "надстроек" над Windows-API, скрыв от программиста-прикладника реальность... я уже говорил - МАТРИЦА... потому вы и не использовали getMessage, т.к. этот вызов происходит где-то в глубинах реализации VCL, MFC или чем вы там пользовались...

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

[Пухич]

Кажется я понял, как вы скатились от кнопок до ОС. Кто-то вспомнил про интерруптную (сказать "прерывайную" язык не поворачивается) схему обработки событий в современных ОС, а остальные доказывают, что на самом деле она не совсем интерруптная, просто не надо проверять наличие событий на месте их возникновения, а вам об этом сообщат. Я согласен со вторыми. Если ваша программа не узнает о событии моментально, а это невозможно для приложений в ОС с вытесняющей многозадачностью, то это мало чем отличается от опроса. Только место опроса смещено. Фактически реально асинхронный способ обработки событий может реализовать только ядро ОС. Но часто "асинхронными" называют совсем другие вещи.

Пример - межпроцессный обмен через разделяемую память в Линухе с квитированием при помощи, например, сигналов SIGUSR1 и SIGUSR2, считается асинхронным. Хотя поступление сигнала будет зафиксировано процессом А не тогда, когда этот сигнал был выдан процессом В, а только тогда, когда процесс А получит квант времени. Т.е. сама работа с сигналами фактически синхронна. Но т.к. посылка сигналов с точки зрения процесса происходит когда ему угодно, а не согласно какой-то общей команде (как в случае с обменом по SIGALRM, например), то это дело условно называетя асинхронным обменом.