Наверное мы термин "принудительно" по-разному понимаем. Сам, потому что это процесс вызывает блокирующие ф.10 или ф.23. Инициатор перехода в режим ожидания сам процесс. Проверил события, если ничего нет поставил флаг ожидания TASKDATA.state=5 и ушёл спать через change_task. Если будет проверять события ф.11, будет работать без остановок. Принудительно вытесняет только планировщик.По идее, при пустой очереди его должны принудительно в спячку переводить, нет?
Не перерисовывается фон, когда неактивное окно изменяет своё положение
По-разному. (Ну и еще я ядро ваше мало изучал пока что, ориентируюсь на общепринятое поведение)Serge wrote:Наверное мы термин "принудительно" по-разному понимаем. Сам, потому что это процесс вызывает блокирующие ф.10 или ф.23. Инициатор перехода в режим ожидания сам процесс. Проверил события, если ничего нет поставил флаг ожидания TASKDATA.state=5 и ушёл спать через change_task. Если будет проверять события ф.11, будет работать без остановок. Принудительно вытесняет только планировщик.По идее, при пустой очереди его должны принудительно в спячку переводить, нет?
Не сам: он сам просит отдать последнее собщение, когда оно будет, он себя усыпить не просит - если мессАж есть на месте, он получит управление тут же. А вот уж ядро думает: нет для тебя касатик, ни фига, сиди спи, не трать процессорное время мне тут Или у вас не так?
Не думает ядро ничего, у него для этого мозгов нет. Делает только то, что программист написал.
Для меня "принудительно" означает, что вытеснение происходит независимо от желания программиста. А когда это ожидаемое поведение функции, ну какая здесь принудительность ?
Еще как просит. Программист. "Если нет сообщений, то спать. Разбудите, когда будут новости". Если не надо спать, применяется ф.11он себя усыпить не просит
Для меня "принудительно" означает, что вытеснение происходит независимо от желания программиста. А когда это ожидаемое поведение функции, ну какая здесь принудительность ?
Это позерство и игра словами. Слово "думает" применено в значении "есть логика для действия Х, которую заложил программист". Уверен, ты понял, о чем я.Serge wrote:Не думает ядро ничего, у него для этого мозгов нет. Делает только то, что программист написал.
Неа. Если сообщения есть, то нужен возврат. Программа не заинтересована в том, чтобы спать, ей это вообще не нужно. В идеале она бы вообще весь процессор под себя подмяла. А вот ядро ее усыпляет, когда той точно делать нечего. Это ядро вызывает условный putToSleepMode(ThreadID), а не программа. Они ж программы, несознательные. Как дети малые. А было б иначе - не нужна была бы нам вытесняющая многозадачность.Еще как просит. Программист. "Если нет сообщений, то спать. Разбудите, когда будут новости". Если не надо спать, применяется ф.11он себя усыпить не просит
Я о внутренней реализации. Потому что блокирующий вызов необзательно через сон реализуется, и может быть реализован просто в лоб: spinиться в течение своего кванта времени, опрашивая очередь сообщений, пока смена контекста не произойдет. Это тоже блокирующий вызов для той же самой Ф10. Просто тупая реализация. А в норме в отсутствие сообщений "по ту сторону", в ядре, поток будет кинут ядром в сон. И там и там - блокирующая Ф10, программа просила одно и то же. А вот в реализации 1 сна нет, в реализации 2 - есть. Так что тут что программа запросила - значения не имеет по отношению ко сну. Она просила не возвращаться, а не спать. Сон - деталь реализации.
Ты лучше вот что скажи: ты упомянул в какой-то теме, что Intel рекомендует использовать MUL вместо IMUL, так как MUL-де быстрее. Не назовешь, что за документ ты имеешь в виду? А то я проглядел ряд документов по оптимизации - везде MUL и IMUL отнесены к одной категории по спариванию и по тактам.
Не надо одушевлять программы и наделять их свободой воли. Программист решает, что лучше для программы и в целом для системы. Реально программе всегда нужно спать, иначе она посадит аккумулятор и перегреет процессор.Программа не заинтересована в том, чтобы спать, ей это вообще не нужно. В идеале она бы вообще весь процессор под себя подмяла.
Ключевая деталь. Программа (программист конечно) просила не тратить процессорное время. Иначе ф.10 просто не нужна, есть ф.11Она просила не возвращаться, а не спать. Сон - деталь реализации.
Ф.10 и 23 это классика кооперативной многозадачности. Их применение как раз говорит о том, что желательна передача управления другому процессу, а не пустая трата циклов в ожидании вытеснения планировщиком. В старых Win, например, принудительного вытеснения не было совсем.
Я разберусь, что надо Это просто фигура речи, не придирайся. Программе не нужно спать. Ей пофигу на аккумулятор, она выполняет поставленную задачу. Задача ОС - разделять ресурсы, втч процессорное время.Serge wrote:Не надо одушевлять программы и наделять их свободой воли. Программист решает, что лучше для программы и в целом для системы. Реально программе всегда нужно спать, иначе она посадит аккумулятор и перегреет процессор.
Не-а. Она просила не возвращаться.Ключевая деталь. Программа (программист конечно) просила не тратить процессорное время.
Представь, что Ф10 реализована тупо (в псевдокоде):
Code: Select all
while (!PeekMessage(Message)) do;
return Message;
Тут - иначе:
Code: Select all
Count = 100;
GotMessage = False;
while (!(GotMessage = PeekMessage(Message))) && (Count > 0) do Count--;
if(!GotMessage)
SleepWaitingFor(MessageQueue);
GotMessage = PeekMessage(Message);
if(GotMessage)
return Message
else
return -1;
Притянуто за уши. Так-то можно считать, что никакие библиотеки не нужны, потому что все можно руками сделать.Иначе ф.10 просто не нужна, есть ф.11
Не-а. API предполагает, что вызов блокирующий. И это все. Представь, что есть альтернативная Колибри, которая реализует тот же самый API, но Ф10 - как в варианте 1. Для программы - никакой разницы, она так же отработает. Усыпляет ее ядро.Их применение как раз говорит о том, что желательна передача управления другому процессу, а не пустая трата циклов в ожидании вытеснения планировщиком
А стырые - это какие? NT 89 года, в которой уже есть WaitForSingleObject - старая?В старых Win, например, принудительного вытеснения не было совсем.
//DG
Тут надо понимать суть происходящего.
Ядро - это всего лишь код. Код, который исполняется процессом, также как и любая функция; считай, библиотека. Когда программа вызывает сисфункцию, происходит смена прав и стека, и программа продолжает работать в ядре. Если программа падает в ядре, завершается её процесс; вся система при этом не падает - её это никак не касается.
Так вот, внутри ф. 10 программа проверяет наличие событий, если их нет - засыпает в ожидании, при этом происходит смена процесса. Применительно к данному багу, программа может в одном потоке заниматься какой-то периодической фоновой деятельностью, а не только рисованием окна.
Тут надо понимать суть происходящего.
Ядро - это всего лишь код. Код, который исполняется процессом, также как и любая функция; считай, библиотека. Когда программа вызывает сисфункцию, происходит смена прав и стека, и программа продолжает работать в ядре. Если программа падает в ядре, завершается её процесс; вся система при этом не падает - её это никак не касается.
Так вот, внутри ф. 10 программа проверяет наличие событий, если их нет - засыпает в ожидании, при этом происходит смена процесса. Применительно к данному багу, программа может в одном потоке заниматься какой-то периодической фоновой деятельностью, а не только рисованием окна.
Эта фигура речи выводит за скобки программиста и переворачивает всё с ног на голову.Это просто фигура речи, не придирайся.
У программы вообще нет потребностей, они есть у программиста.Программе не нужно спать.
Не-а. Она просила не возвращаться.
Может обратиться к официальной документации ?Не-а. API предполагает, что вызов блокирующий. И это все.
Code: Select all
======================================================================
==================== Функция 10 - ожидать события. ===================
======================================================================
Если очередь сообщений пуста, то ждет появления сообщения в очереди.
В таком состоянии поток не получает процессорного времени.
Затем считывает сообщение из очереди.
======================================================================
==================== Function 10 - wait for event. ===================
======================================================================
If the message queue is empty, waits for appearance of the message
in queue. In this state thread does not consume CPU time.
Then reads out the message from queue.
не получает процессорного времени
does not consume CPU time
Windows 1.0 - 3.х Старые операционки от Apple тоже были с кооперативной многозадачностью. И оставались такими, пока Джобс не вернулся.А стырые - это какие?
Я, разумеется, понимаю это. Это вопрос терминологии - "ядро делает" = код ядра делает, пусть даже в потоке исполнения самой программы. Ясно, что ядро - не отдельный поток.Pathoswithin wrote://DG
Тут надо понимать суть происходящего.
Ядро - это всего лишь код. Код, который исполняется процессом, также как и любая функция; считай, библиотека. Когда программа вызывает сисфункцию, происходит смена прав и стека, и программа продолжает работать в ядре. Если программа падает в ядре, завершается её процесс; вся система при этом не падает - её это никак не касается.
Так вот, внутри ф. 10 программа проверяет наличие событий, если их нет - засыпает в ожидании, при этом происходит смена процесса. Применительно к данному багу, программа может в одном потоке заниматься какой-то периодической фоновой деятельностью, а не только рисованием окна.
Да никоим образом. И так понятно, что программа - не субъект. Когда мы говорим "программа делает", или "программе нужно", понятно, что речь идет о логике, заложенной программистом. Придираться здесь так же нелепо, как и ко фразе "поезд сбил человека", мол не поезд, а машинист, это же он управлял.Serge wrote:Эта фигура речи выводит за скобки программиста и переворачивает всё с ног на голову.Это просто фигура речи, не придирайся.
Игра слов, не более. См. выше. Программе, выполняющей задачу, обслуживающей потребности программиста, не нужно спать, ей нужно выполнять задачу, разделяя время с другими программами. "Спать" - это не задача программы, это вынужденное состояние простоя, побочка в чистом виде.У программы вообще нет потребностей, они есть у программиста.
Еще было бы неплохо понимать, что программа и ядро могут быть написаны разными людьми, у которых разные устремления, выраженные через их ПО.
Отлично. Смотри сам: программа не получает. Не получает, потому что является зависимым объектом, не она решает, сколько квантов времени она будет занимать процессор.Здесь не предположение, здесь прямо написано
не получает процессорного времени
Ты что писал?
Как процесс может сам перейти в такое состояние, если его принудительно усыпили и лишили процессорного времени внутри системного вызова, т.е. в ядре, кодом, созданным другим программистом для других целей? Если процесс вызывает функцию вида Sleep(10), он иницирует сон, в Ф10 же сон побочное действие. В Ф10 для процесса нет разницы - усыпили его или нет, для него это все равно миг: нырнул в сискол - вернулся.Но это процесс сам в такое состояние переходит.
Твой аргумент сводится к тому, что процесс усыпляет себя сам, потому что он сам просит себя усыпить, если надо. Я же говорю, что если он просит, то он не выполняет действия самостоятельно, его выполняет код ядра (написанный другим программистом в общем случае). Да, в том же потоке выполнения, но это деталь реализации. Здесь просто терминологическая разница: ты и pathoswithin считаете, что "тело" сискола - это процесс, потому что выполняется потоком исполнения процесса, я же считаю это ядром, потому что это отдельный участок кода, написанный другим разработчиком для других целей, который может что-либо сделать принудительно на нулевом кольце, в отличие от кода третьего кольца, которое и выполнялось потоком исполнения до входа в сискол.
Мы действительно по-разному понимаем термин "принудительно", забей. Это мелочь.
Ты лучше про MUL и IMUL поясни.
Как раз не деталь. Передача управления другому потоку её ключевая особенность. Кстати та самая PeekMessage из WinAPI тоже передаёт управление, если программист не поставит PM_NOYIELD. Наследство кооперативной многозадачности.Да, в том же потоке выполнения, но это деталь реализации.
Вот поэтому учёные и говорят: "Сначала надо определиться с терминологией"Мы действительно по-разному понимаем термин "принудительно", забей. Это мелочь.
Не нашёл уже. Наверное эта рекомендация была для очень старых процессоров.Ты лучше про MUL и IMUL поясни.
Кстати, так, к слову. Сейчас у меня закончится один серьезный проект на работе, будет больше времени. Я буду делать RTL для FPC с ООП обвязкой для box_lib. Есть ли что-нибудь, над чем нужно потрудиться в ядре? Относительно отдельный участок.
Ты не понял - передача кванта другому потоку - не деталь, это ключевая особенность, верно. Я сказал, что деталь - реализуется ли это текущим потоком исполнения, или иным. Потому что с т.з. прикладной программы не будет разницы, если данное действие выполнит другой поток - для нее вызов будет по-прежнему блокирующим с возможным засыпанием.Как раз не деталь. Передача управления другому потоку её ключевая особенность.
Если сдвигаем окно на 1 пиксель вбок, то окно под ним не отрисовывает этот 1 пиксель.
- Attachments
-
-
wnd.png (35.37 KiB)Viewed 9347 times
-
Из хаоса в космос
Who is online
Users browsing this forum: No registered users and 1 guest