форум программистов
https://www.developing.ru/
А при чём здесь мои знания? И каким боком выдача прерываний в приладу к защищённой системе? Не DOS всё таки.somewhere писал(а):Всмысле? А как же IRQ0? А как же HPET? Ты же вроде знаешь ассемблер...
Нет. Это означает, что по истечении кванта система самостоятельно забирает управление и передаёт другому потоку того же, или другого процесса. И кто сказал, что она бесполезна? Именно вторичный поток делала то, ради чего и была создана вся программа. В первой версии в нём ещё крутился счётчик, а первичный замерял время и вычислял количество повторений в секунду, во второй версии вторичный поток сам опрашивал часы, чтоб притормаживаться слыпом.Absurd писал(а):Это означает что каждый квант времени отданный твоему треду будет сожран целиком на бесполезную херню, хотя можно было бы его передать более полезному процессу либо поместить ядро в состояние останова.
Ну ка попробуйте дать определение такого потока. Это вообще что? Поток, не выводящий на экран ни каких промежуточных результатов и не управляемый в процессе работы? Система не может гарантировать подобного режима. Поток, не выводящий информацию непосредственно, а только посредством другого потока? У меня было на столько всё вывернуто шиворот на выворот, что этим свойством обладал именно первичный поток. А вторичный поток - это поток, запущенный из другого потока своего процесса. Всё просто и понятно и не требуются ни какие гарантии ограничений операционной системы. Кстати, словосочетание "первичный поток" есть у Петзолдта. Если один первичный, то остальные какие? Что то у Вас не вяжется.Absurd писал(а):Нет вторичных потоков. Есть фоновые (BACKGROUND).
Согласно правилу, по которому определяется, нужна ли приложению многопоточность, действия, занимающие меньше 1/10 секунды выполняются в первичном потоке, а во вторичные выносится только то, что занимает больше времени. Читайте Петзолдта. Ради пробы клавы можно вынести во вторичный поток и краткую операцию, но если дальше идёт синхронизация, то получаем недоиспользование процессора, такую операцию эффективней выполнять или прямо в оконной процедуре, или в функции, вызываемой из неё. А вот если действие занимает часа полтора, то в это время должны продолжать получаться и обрабатываться сообщения и только по выполнении всего задания или его части, занимающей хоятыбы секунд 10 по времени, происходит вывод результата, окончательного или промежуточного. Кстати, синхронизацию при доступе к экранному компоненту я использовал только в тестовом приложении и только на болэнде. И ни разу в реальном проекте. Предпочитаю монополизировать вывод одним потоком и такой фигнёй не заниматься. Первичный поток отлично может получить сами данные и по булеву флагу самостоятельно вывести их на экран. Такой флаг достаточно мал для атомарности операций с ним, а непредсказуемых изменений данных после его установки можно ведь и не прописывать. Была у меня и тестилка, где оба потока пытались рисовать. Фигня получилась.Absurd писал(а):Обычно предполагается что когда твой тред получит квант времени он быстро сделает что-то и повиснет на объекте синхронизации или ожидании ввода-вывода.
Бред. Приоритет - это задание. Разумеется ОС не даёт всё время только самому приоритетному потоку. Но если бы приоритет игнорился, то его бы просто не было. Но приоритеты есть, поэтому если несколько потоков имеют разные приоритеты, то больше времени получает более приоритетный, менее же приориетные начнут "тормозить" первыми. Если несколько потоков имеют высший приоритет и в сумме не хватает, то "Тормозить" будет всё.Absurd писал(а):Приоритет это хотелка. ОС имеет право не принимать ее во внимание.
Жульничает в польузу? Эйси. А в ущерб чему? Тем же самым пользовательским программам? Не смешно.Absurd писал(а):Windows, например, жульничает в пользу активных пользовательских программ чтобы достигнуть лучшей отзывчивости интерфейса.
Ну ка попробуйте дать определение такого потока. Это вообще что? Поток, не выводящий на экран ни каких промежуточных результатов и не управляемый в процессе работы? Система не может гарантировать подобного режима. Поток, не выводящий информацию непосредственно, а только посредством другого потока? У меня было на столько всё вывернуто шиворот на выворот, что этим свойством обладал именно первичный поток. А вторичный поток - это поток, запущенный из другого потока своего процесса. Всё просто и понятно и не требуются ни какие гарантии ограничений операционной системы. Кстати, словосочетание "первичный поток" есть у Петзолдта. Если один первичный, то остальные какие? Что то у Вас не вяжется.Absurd писал(а):Нет вторичных потоков. Есть фоновые (BACKGROUND).
Согласно правилу, по которому определяется, нужна ли приложению многопоточность, действия, занимающие меньше 1/10 секунды выполняются в первичном потоке, а во вторичные выносится только то, что занимает больше времени. Читайте Петзолдта. Ради пробы клавы можно вынести во вторичный поток и краткую операцию, но если дальше идёт синхронизация, то получаем недоиспользование процессора, такую операцию эффективней выполнять или прямо в оконной процедуре, или в функции, вызываемой из неё. А вот если действие занимает часа полтора, то в это время должны продолжать получаться и обрабатываться сообщения и только по выполнении всего задания или его части, занимающей хоятыбы секунд 10 по времени, происходит вывод результата, окончательного или промежуточного. Кстати, синхронизацию при доступе к экранному компоненту я использовал только в тестовом приложении и только на болэнде. И ни разу в реальном проекте. Предпочитаю монополизировать вывод одним потоком и такой фигнёй не заниматься. Первичный поток отлично может получить сами данные и по булеву флагу самостоятельно вывести их на экран. Такой флаг достаточно мал для атомарности операций с ним, а непредсказуемых изменений данных после его установки можно ведь и не прописывать. Была у меня и тестилка, где оба потока пытались рисовать. Фигня получилась.Absurd писал(а):Обычно предполагается что когда твой тред получит квант времени он быстро сделает что-то и повиснет на объекте синхронизации или ожидании ввода-вывода.
Бред. Приоритет - это задание. Разумеется ОС не даёт всё время только самому приоритетному потоку. Но если бы приоритет игнорился, то его бы просто не было. Но приоритеты есть, поэтому если несколько потоков имеют разные приоритеты, то больше времени получает более приоритетный, менее же приориетные начнут "тормозить" первыми. Если несколько потоков имеют высший приоритет и в сумме не хватает, то "Тормозить" будет всё.Absurd писал(а):Приоритет это хотелка. ОС имеет право не принимать ее во внимание.
Жульничает в польузу? Эйси. А в ущерб чему? Тем же самым пользовательским программам? Не смешно.Absurd писал(а):Windows, например, жульничает в пользу активных пользовательских программ чтобы достигнуть лучшей отзывчивости интерфейса.
Ну ка какой пинг у единственного на планете сервера некоторого сервиса? О реактивности интерфейса с таким пингом можно забыть. Сервер в каждом городе? И сколько ты будешь ждать удовлетворения заявки на установку такого то приложения? Ведь всем без исключения всё подряд не нужно, а прога могла быть ещё и написана после запуска городского сервера. Неделю? Мне бы твой оптимизм. Или всем подряд выдать админские привилегии? Поздравляю, можешь выбросить сервера. Причём, на саму связь с ближайшим ретранслятором энергия тоже тратится, в зависимости от условий связи по-разному. В Новокузнецке телефон может две-три недели протянуть на одной зарядке, в Крапивино аккумулятор на одной лишь проверке "А в сети ли я?" садится в ноль меньше, чем за сутки, а в режиме разговора аккумулятор по паспорту рассчитан всего на 4 часа, даже если весь разговор сидеть возле самого ретранслятора. Так что в сервера имеет смысл выносить только резервные файлы и то, что должно быть централизовано по самой своей сути. Общую для многих пользователей БД, модель Земли (она у нас одна), игровой мир какого нибудь мультиплеера.... Всё остальное должно быть локально.Absurd писал(а):Кроме того, в прошлом постинге я забыл упомянуть что мы живем в эпоху облачных платформ и мобильных устройств. На мобильном устройстве бессмыссленное вращение в лупе из нескольких инструкций эффективно сажает аккумулятор. В облаке все нормально пока вы исправно платите провайдеру облачного сервиса за электричество.
То есть ты думаешь, что в protected mode нет IRQ ? ужас)) я в шокеИ каким боком выдача прерываний в приладу к защищённой системе? Не DOS всё таки.
Intel Core I7 3.06GHz выполняет в среднем 18 миллионов инструкций в секунду. Допустим что проверка таймера это 10 инструкций, а гранулярность шедулера - 1 секунда. Задача: выяснить количество бесполезной херни.И кто сказал, что она бесполезна?
Если треду назначен приоритет BACKGROUND (THREAD_PRIORITY_LOWEST, THREAD_MODE_BACKGROUND_BEGIN...THREAD_MODE_BACKGROUND_END)Нет вторичных потоков. Есть фоновые (BACKGROUND).Ну ка попробуйте дать определение такого потока.
Петцольд пишет про отзывчивость пользовательского интерфейса. Если в обработчик меню или кнопки поместить деятельность которая выполняется порядка секунды или более, то GUI будет работать плохо. Но выход из такой ситуации это не обязательно введение дополнительных тредов. Можно использовать континуации и асинхронный ввод-вывод.Согласно правилу, по которому определяется, нужна ли приложению многопоточность, действия, занимающие меньше 1/10 секунды выполняются в первичном потоке, а во вторичные выносится только то, что занимает больше времени. Читайте Петзолдта.
Приоритет это мнение программиста о том насколько значимым является данный тред. Есть еще мнение ОС, которая собственно и решает кому сколько давать.Бред. Приоритет - это задание.
Я попытался предположить что Эй Си это буквы английского алфавита, и соответственно какая-то англоязычная аббревиатура.Жульничает в польузу? Эйси.
В пользу тех тредов, которые с точки зрения Windows представляют наибольший интерес для пользователя. Т.е. приоритет Windows рассчитывает сама по своей внутренней логике.А в ущерб чему? Тем же самым пользовательским программам?