Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Вс май 28, 2017 12:12 am

Часовой пояс: UTC+03:00




Начать новую тему  Ответить на тему  [ 27 сообщений ]  На страницу Пред. 1 2
Автор Сообщение
СообщениеДобавлено: Пт окт 14, 2016 2:37 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3925
Цитата:
По идее, при пустой очереди его должны принудительно в спячку переводить, нет?
Наверное мы термин "принудительно" по-разному понимаем. Сам, потому что это процесс вызывает блокирующие ф.10 или ф.23. Инициатор перехода в режим ожидания сам процесс. Проверил события, если ничего нет поставил флаг ожидания TASKDATA.state=5 и ушёл спать через change_task. Если будет проверять события ф.11, будет работать без остановок. Принудительно вытесняет только планировщик.


Вернуться к началу
СообщениеДобавлено: Пт окт 14, 2016 2:56 pm 
Не в сети

Зарегистрирован: Вт окт 04, 2016 10:05 pm
Сообщения: 44
Serge писал(а):
Цитата:
По идее, при пустой очереди его должны принудительно в спячку переводить, нет?
Наверное мы термин "принудительно" по-разному понимаем. Сам, потому что это процесс вызывает блокирующие ф.10 или ф.23. Инициатор перехода в режим ожидания сам процесс. Проверил события, если ничего нет поставил флаг ожидания TASKDATA.state=5 и ушёл спать через change_task. Если будет проверять события ф.11, будет работать без остановок. Принудительно вытесняет только планировщик.

По-разному. (Ну и еще я ядро ваше мало изучал пока что, ориентируюсь на общепринятое поведение)
Не сам: он сам просит отдать последнее собщение, когда оно будет, он себя усыпить не просит - если мессАж есть на месте, он получит управление тут же. А вот уж ядро думает: нет для тебя касатик, ни фига, сиди спи, не трать процессорное время мне тут :lol: Или у вас не так?


Вернуться к началу
СообщениеДобавлено: Пт окт 14, 2016 4:23 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3925
Не думает ядро ничего, у него для этого мозгов нет. Делает только то, что программист написал.
Цитата:
он себя усыпить не просит
Еще как просит. Программист. "Если нет сообщений, то спать. Разбудите, когда будут новости". Если не надо спать, применяется ф.11
Для меня "принудительно" означает, что вытеснение происходит независимо от желания программиста. А когда это ожидаемое поведение функции, ну какая здесь принудительность ?


Вернуться к началу
СообщениеДобавлено: Пт окт 14, 2016 4:34 pm 
Не в сети

Зарегистрирован: Вт окт 04, 2016 10:05 pm
Сообщения: 44
Serge писал(а):
Не думает ядро ничего, у него для этого мозгов нет. Делает только то, что программист написал.

Это позерство и игра словами. Слово "думает" применено в значении "есть логика для действия Х, которую заложил программист". Уверен, ты понял, о чем я.

Цитата:
Цитата:
он себя усыпить не просит
Еще как просит. Программист. "Если нет сообщений, то спать. Разбудите, когда будут новости". Если не надо спать, применяется ф.11

Неа. Если сообщения есть, то нужен возврат. Программа не заинтересована в том, чтобы спать, ей это вообще не нужно. В идеале она бы вообще весь процессор под себя подмяла. А вот ядро ее усыпляет, когда той точно делать нечего. Это ядро вызывает условный putToSleepMode(ThreadID), а не программа. Они ж программы, несознательные. Как дети малые. А было б иначе - не нужна была бы нам вытесняющая многозадачность.

Я о внутренней реализации. Потому что блокирующий вызов необзательно через сон реализуется, и может быть реализован просто в лоб: spinиться в течение своего кванта времени, опрашивая очередь сообщений, пока смена контекста не произойдет. Это тоже блокирующий вызов для той же самой Ф10. Просто тупая реализация. А в норме в отсутствие сообщений "по ту сторону", в ядре, поток будет кинут ядром в сон. И там и там - блокирующая Ф10, программа просила одно и то же. А вот в реализации 1 сна нет, в реализации 2 - есть. Так что тут что программа запросила - значения не имеет по отношению ко сну. Она просила не возвращаться, а не спать. Сон - деталь реализации.

Ты лучше вот что скажи: ты упомянул в какой-то теме, что Intel рекомендует использовать MUL вместо IMUL, так как MUL-де быстрее. Не назовешь, что за документ ты имеешь в виду? А то я проглядел ряд документов по оптимизации - везде MUL и IMUL отнесены к одной категории по спариванию и по тактам.


Вернуться к началу
СообщениеДобавлено: Пт окт 14, 2016 5:12 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3925
Цитата:
Программа не заинтересована в том, чтобы спать, ей это вообще не нужно. В идеале она бы вообще весь процессор под себя подмяла.
Не надо одушевлять программы и наделять их свободой воли. Программист решает, что лучше для программы и в целом для системы. Реально программе всегда нужно спать, иначе она посадит аккумулятор и перегреет процессор.
Цитата:
Она просила не возвращаться, а не спать. Сон - деталь реализации.
Ключевая деталь. Программа (программист конечно) просила не тратить процессорное время. Иначе ф.10 просто не нужна, есть ф.11
Ф.10 и 23 это классика кооперативной многозадачности. Их применение как раз говорит о том, что желательна передача управления другому процессу, а не пустая трата циклов в ожидании вытеснения планировщиком. В старых Win, например, принудительного вытеснения не было совсем.


Вернуться к началу
СообщениеДобавлено: Пт окт 14, 2016 5:38 pm 
Не в сети

Зарегистрирован: Вт окт 04, 2016 10:05 pm
Сообщения: 44
Serge писал(а):
Не надо одушевлять программы и наделять их свободой воли. Программист решает, что лучше для программы и в целом для системы. Реально программе всегда нужно спать, иначе она посадит аккумулятор и перегреет процессор.

Я разберусь, что надо :wink: Это просто фигура речи, не придирайся. Программе не нужно спать. Ей пофигу на аккумулятор, она выполняет поставленную задачу. Задача ОС - разделять ресурсы, втч процессорное время.

Цитата:
Ключевая деталь. Программа (программист конечно) просила не тратить процессорное время.

Не-а. Она просила не возвращаться.
Представь, что Ф10 реализована тупо (в псевдокоде):

Код:
while (!PeekMessage(Message)) do;
return Message;

Вызов блокирующий? Да. А сна - нет. Потому что ядерная часть вызова не усыпила поток.

Тут - иначе:
Код:
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. Для программы - никакой разницы, она так же отработает. Усыпляет ее ядро.

Цитата:
В старых Win, например, принудительного вытеснения не было совсем.

А стырые - это какие? NT 89 года, в которой уже есть WaitForSingleObject - старая?


Вернуться к началу
СообщениеДобавлено: Пт окт 14, 2016 5:50 pm 
Не в сети
Mentor/Kernel Developer
Аватара пользователя

Зарегистрирован: Чт мар 26, 2015 5:16 pm
Сообщения: 1138
//DG
Тут надо понимать суть происходящего.
Ядро - это всего лишь код. Код, который исполняется процессом, также как и любая функция; считай, библиотека. Когда программа вызывает сисфункцию, происходит смена прав и стека, и программа продолжает работать в ядре. Если программа падает в ядре, завершается её процесс; вся система при этом не падает - её это никак не касается.

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


Вернуться к началу
СообщениеДобавлено: Пт окт 14, 2016 6:25 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3925
Цитата:
Это просто фигура речи, не придирайся.
Эта фигура речи выводит за скобки программиста и переворачивает всё с ног на голову.
Цитата:
Программе не нужно спать.
У программы вообще нет потребностей, они есть у программиста.
Цитата:
Не-а. Она просила не возвращаться.
Цитата:
Не-а. API предполагает, что вызов блокирующий. И это все.
Может обратиться к официальной документации ?
Код:
======================================================================
==================== Функция 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 тоже были с кооперативной многозадачностью. И оставались такими, пока Джобс не вернулся.


Вернуться к началу
СообщениеДобавлено: Пт окт 14, 2016 7:05 pm 
Не в сети

Зарегистрирован: Вт окт 04, 2016 10:05 pm
Сообщения: 44
Pathoswithin писал(а):
//DG
Тут надо понимать суть происходящего.
Ядро - это всего лишь код. Код, который исполняется процессом, также как и любая функция; считай, библиотека. Когда программа вызывает сисфункцию, происходит смена прав и стека, и программа продолжает работать в ядре. Если программа падает в ядре, завершается её процесс; вся система при этом не падает - её это никак не касается.

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

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


Вернуться к началу
СообщениеДобавлено: Пт окт 14, 2016 7:24 pm 
Не в сети

Зарегистрирован: Вт окт 04, 2016 10:05 pm
Сообщения: 44
Serge писал(а):
Цитата:
Это просто фигура речи, не придирайся.
Эта фигура речи выводит за скобки программиста и переворачивает всё с ног на голову.

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

Цитата:
У программы вообще нет потребностей, они есть у программиста.

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

Цитата:
Здесь не предположение, здесь прямо написано
не получает процессорного времени

Отлично. Смотри сам: программа не получает. Не получает, потому что является зависимым объектом, не она решает, сколько квантов времени она будет занимать процессор.
Ты что писал?
Цитата:
Но это процесс сам в такое состояние переходит.

Как процесс может сам перейти в такое состояние, если его принудительно усыпили и лишили процессорного времени внутри системного вызова, т.е. в ядре, кодом, созданным другим программистом для других целей? Если процесс вызывает функцию вида Sleep(10), он иницирует сон, в Ф10 же сон побочное действие. В Ф10 для процесса нет разницы - усыпили его или нет, для него это все равно миг: нырнул в сискол - вернулся.

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

Мы действительно по-разному понимаем термин "принудительно", забей. Это мелочь.
Ты лучше про MUL и IMUL поясни.


Вернуться к началу
СообщениеДобавлено: Пт окт 14, 2016 7:42 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3925
Цитата:
Да, в том же потоке выполнения, но это деталь реализации.
Как раз не деталь. Передача управления другому потоку её ключевая особенность. Кстати та самая PeekMessage из WinAPI тоже передаёт управление, если программист не поставит PM_NOYIELD. Наследство кооперативной многозадачности.
Цитата:
Мы действительно по-разному понимаем термин "принудительно", забей. Это мелочь.
Вот поэтому учёные и говорят: "Сначала надо определиться с терминологией"
Цитата:
Ты лучше про MUL и IMUL поясни.
Не нашёл уже. Наверное эта рекомендация была для очень старых процессоров.


Вернуться к началу
СообщениеДобавлено: Пт окт 14, 2016 7:45 pm 
Не в сети

Зарегистрирован: Вт окт 04, 2016 10:05 pm
Сообщения: 44
Кстати, так, к слову. Сейчас у меня закончится один серьезный проект на работе, будет больше времени. Я буду делать RTL для FPC с ООП обвязкой для box_lib. Есть ли что-нибудь, над чем нужно потрудиться в ядре? Относительно отдельный участок.

Цитата:
Как раз не деталь. Передача управления другому потоку её ключевая особенность.

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


Вернуться к началу
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 27 сообщений ]  На страницу Пред. 1 2

Часовой пояс: UTC+03:00


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB