Форум РадиоКот

ARV писал(а):Когда все процессы просмотрены, происходит возврат из той самой getMessage с кодом "очередь пуста" и программа отрабатывает ситуацию IDLE - т.е. простой.

Вон как! Вот этого описания нигде не встречал (или не запомнил) - где об этом можно прочитать?

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

Windows
Пишутся обработчики для различных событий - пришло сообщение "нажата клавиша" запускается подпрограмма его обработки, пришло сообщение "перерисовать экран" -делаем и т.д.
Пока программа успевает обрабатывать события никаких проблем не возникает, разве что программа требует несколько больше памяти. Создается ощущение что все кусочки работают параллельно. Ситуация усложняется если программа обработки требует много времени. Тогда возникает "подвисание" программы.
Одним из способов борьбы с подвисанием может быть искуственное прерывание программы обработчика, но это уже требует повышения качества программирования: учета возможности изменения обрабатываемых параметров, запуска дополнительных экземпляров той же программы, принятия решения о нужности - ненужности продолжения и т.п.
Что касается микроконтроллеров то работа с запрещенным прерыванием очень напоминает классическую дос-программу. При этом программы получаются компактные, но работать с оборудованием удобно только последовательно.
Использование прерываний позволяет легко использовать сразу несколько внешних устройств. Но расплачиваться за это приходится более сложной программой.

dremov
Не совсем так. Прерывания и в ДОС активно пользовались. Да и о многопоточности в винде забыли

Yellow Tiger писал(а):

ARV писал(а):Когда все процессы просмотрены, происходит возврат из той самой getMessage с кодом "очередь пуста" и программа отрабатывает ситуацию IDLE - т.е. простой.

Вон как! Вот этого описания нигде не встречал (или не запомнил) - где об этом можно прочитать?

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

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

То есть выходит, что количество одновременно выполняющихся потоков ограничено ресурсами процессора. И это можно проверить - создать несколько десятков тысяч потоков которые будут просто в бесконечном цикле вызывать sleep(20000). Когда число достигнет предела, то мы получим одно из следующих последствий:
1) ОС просто вернет ошибку при следующем вызове CreateThread
2) Насильно завершит "бунтующую" программу
3) ОС упадет и перестанет функционировать корректно до перезагрузки (в последнем очень сомневаюсь)
В общем, нужно бы в свободное время проверить...

Добавлено: Программа под .NET Framework создала 1380 потоков, а при попытке создания 1381-го все потоки этой программы благополучно повисли намертво, пришлось снимать процесс диспетчером. Сама винда не повисла - этого и следовало ожидать. Попробую еще на чистом АПИ, но это позже.

ARV писал(а):... похоже, я заблуждался.

Ааа, ну, тогда понятно, почему у Руссиновича об этом не было ни слова.

Foks писал(а):...при попытке создания 1381-го все потоки этой программы благополучно повисли намертво, ... Сама винда не повисла - этого и следовало ожидать.

Выходит, процессор знает, когда он переключается на винду(!), и при переключении на неё не использует этот аппаратный механизм, а сохраняет все по-простому, без изысков?

Yellow Tiger писал(а):Выходит, процессор знает, когда он переключается на винду(!), и при переключении на неё не использует этот аппаратный механизм, а сохраняет все по-простому, без изысков?

Сомневаюсь Скорее всего просто .NET Framework неправильно отработал при попытке создания нового потока, и благополучно повесил программу.
Да и вообще, нужно было сразу под ВинАпи проверять - эти навороченные фреймворки никогда не работают как надо...

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

число потоков ограничивается параметрами локальной кучи (heap), выделяемой процессу. если этой фреймворк затребовал кучу скажем в 1 мегабайт, и при этом не имеет возможности (или не считает нужным) увеличивать ее по мере исчерпания, то как только число хендлов открытых потоков (а ведь каждый хендл - это довольно приличный кусок памяти по сути) станет таким, что куча будет исчерпана - все, больше ничего не выйдет. эта проблема была всегда, во всех версиях Windows, да и наверное свойственна любым ОС. То, что 32-разрядная ОС теоретически может предоставлять потоку (программе) огромное место для ее кучи - еще ни о чем не говорит, ведь мало иметь возможность, надо еще ею пользоваться...

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

Ну если очень хочется извратиться то можно в вектор аппаратного прерывания поместить селектор дескриптора задачи.
Тогда при возникновении аппаратного прерывания толжно произойти аппаратное переключение контекстов.
Другой вопрос что так не делают, потому что от планировщика ядра кроме переключения задач требуется собственно ПЛАНИРОВКА процесса переключения... но теоретически это возможно...

NiTr0 писал(а): Не совсем так. Прерывания и в ДОС активно пользовались. Да и о многопоточности в винде забыли

На самом деле не все так грустно. Но я хотел сказать что все же прерывания вещь полезная и жизнь облегчают. А вот ARV их вообще запретить хотел.

dremov писал(а):А вот ARV их вообще запретить хотел.

ну да. и пизанскую башню повалил тоже ARV