Developing.ru

Absurd писал(а):WM_TIMER чтоли? О них речь не шла.

Вот же:

Decoder писал(а):Выдержка нужных интервалов времени обеспечивается именно таймером.

. Так что не надо.

Absurd писал(а):Но crond который не съедает целиком одно ядро люди как-то пишут.

Кто такой?

Absurd писал(а):Ванильные Винда и Линукс вообще не реалтаймовые ОС.

Слово "приблизительно" знакомо? Чем надежда от гарантии отличается знаешь?

Absurd писал(а):Нужен реалтайм - покупай PLC и щелкай в ней герконами.

Есть ещё фотон. Это виндоусподобная (внешне) ОС реального времени.

Сионист, ты даже не представляешь, как подставился... Я даже не знаю, с какой стороны начать объяснять тебе, что ты профан, так как здесь с какой стороны не возьмись, перспективы по унижению просто неимоверные. Изо всех сил сдерживаю себя, чтобы не написать целый ворох гадостей весьма колких и болезненных. Пожалуй, сделаю скидку на возраст и просто объясняю на пальцах, что multhi-trhreading programming у тебя на уровне даже не студента (как С++), а как школьника.

Понимаешь, гонять в отдельной треде бесконечный цикл, проверяющий условие - это обозначает забить одно ядро процессора на 100%. Тебе на это сразу же указал Absurd, но ты будто бы не заметил его слов и, как обычно, продолжил флудить о чём-то слабо связанном с данной темой. Запомни на будущее, если будешь когда либо реализовывать подобное, в любом случае нужно делать sleep, давая возможность операционной системе выполнить на ядре другие потоки, которые нуждаются в процессорном времени. Вряд ли задача подразумевает точность срабатывание планировщика выше, чем в одну секунду, так что спокойно можно проверять время раз в секунду. Даже такая незамысловатая оптимизация колоссально разгрузит ядро. По хорошему же, твой подход вообще нужно выбрасывать, как неприемлемый: нам ведь ничего не стоит проверить сколько времени осталось до ближайшей по приоритету задачи и заснуть именно на такое время. Следует учесть, конечно, максимально возможные диапазон "сна", который может получить sleep, и, возможно, разбить на промежутки несколько кусков, но если использовать бустовую обёртку, то об этом можно не задумываться, она всё это умеет делать автоматически.

Далее по другим глупостям, написанным тобой, но уже с меньшими подробностями.

- Таймер имелся в виду как понятие, а не как объект Windows. Например в Линуксе есть свой. И, если уж на то пошло, лучше бы ты Windows таймер использовал, чем крутил бесконечный цикл без thread yield.

- Позор не знать cron - это никсовый планировщик заданий.

- Обсуждения ОС реального времени вообще никак не относится к данной теме. Не флуди.

А ещё, я склеил твои сообщения. В глазах рябит от десятка сообщений по одной фразе в каждом. Ты что, счётчик накручиваешь или просто мысли настолько отрывочны в голове, что не можешь их организоваться в один обстоятельный пост?

Romeo писал(а):Сионист, ты даже не представляешь, как подставился... Я даже не знаю, с какой стороны начать объяснять тебе, что ты профан, так как здесь с какой стороны не возьмись, перспективы по унижению просто неимоверные. Изо всех сил сдерживаю себя, чтобы не написать целый ворох гадостей весьма колких и болезненных. Пожалуй, сделаю скидку на возраст и просто объясняю на пальцах, что multhi-trhreading programming у тебя на уровне даже не студента (как С++), а как школьника.

Понимаешь, гонять в отдельной треде бесконечный цикл, проверяющий условие - это обозначает забить одно ядро процессора на 100%. Тебе на это сразу же указал Absurd, но ты будто бы не заметил его слов и, как обычно, продолжил флудить о чём-то слабо связанном с данной темой. Запомни на будущее, если будешь когда либо реализовывать подобное, в любом случае нужно делать sleep, давая возможность операционной системе выполнить на ядре другие потоки, которые нуждаются в процессорном времени.

Вот кто подставился то. В отличии от меня: стыдно быть не настоящим новичком, а липовым экспертом. Мне, кстати, не 90, чтоб скидку на возраст давать. Процессор одноядерный, слыпа нет, цикл бесконечный, поток вторичный, при этом первичный поток успевает обрабатывать сообщения и даже работают другие процессы. Многозадачность в винде с 95-го года вытесняющая. Слып я, кстати, пробовал, вторичный поток стал получать управление менее тысячи раз в секунду, без него тело цикла выполнялось более пяти тысяч раз в секунду. И была это первая проба клавы на тему потоков, а здесь помянута только для того, чтоб указать на то, что:
1. Проверять часы в принципе можно и не по таймеру.
2. Интервал опроса часов выдерживать не нужно, надо только обеспечить, чтоб он не был больше требуемой точности момента запуска запланированной задачи.
Теперь по поводу грева ядра:
1. Если приоритеты потоков не достаточно разнообразны, это проблема не моя, а конкретной оси.
2. Если кто то вообще не знает о приоритетах, то это его личная проблема.
3. Если действительно необходима частая проверка часов, то грев ядра вытекает из задачи через её ресурсоёмкость. И ни каким слыпом от него в этом случае не избавиться.
А теперь вопрос, чтоб окончательно посадить тебя в лужу: а для чего ж мне вообще могла понадобиться проверка часов в цикле, кроме как для слыпа по условию? Планировщиками то я не занимаюсь и даже не располагаю знаниями для запуска одного процесса из другого. Не подскажешь, кто мне новичковую книгу советовал? Причём, после моего поста о том, что подробную описаловку даже базовых операторов я ещё не читал. Ну сейчас то уже читаю, но до такого не дошёл. Остаётся два варианта: пересчёт приращения, с чем отлично справится и первичный поток, а усложнять прогу вторичным не нужно, но цикл именно во вторичном потоке и условный слып.

Romeo писал(а):СионистА ещё, я склеил твои сообщения. В глазах рябит от десятка сообщений по одной фразе в каждом. Ты что, счётчик накручиваешь или просто мысли настолько отрывочны в голове, что не можешь их организоваться в один обстоятельный пост?

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

Romeo писал(а):СионистА ещё, я склеил твои сообщения. В глазах рябит от десятка сообщений по одной фразе в каждом. Ты что, счётчик накручиваешь или просто мысли настолько отрывочны в голове, что не можешь их организоваться в один обстоятельный пост?

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

Romeo писал(а):- Таймер имелся в виду как понятие, а не как объект Windows. Например в Линуксе есть свой. И, если уж на то пошло, лучше бы ты Windows таймер использовал, чем крутил бесконечный цикл без thread yield.

1. Вопрос реализации, не более. Какие бы таймеры ни были в никсах, они тоже заставляют систему дёргать приложения с заданной частотой, но дёргать не аппаратными прерываниями, а более высокоуровневыми средствами.
2. С какого поста началось обсуждение других осей?

Romeo писал(а):- Обсуждения ОС реального времени вообще никак не относится к данной теме. Не флуди.

не я его начал.

Romeo писал(а):- Позор не знать cron - это никсовый планировщик заданий.

А с какого перепугу я вообще должен знать, что никсам нужен планирощик задач? Дефрагментатора то там нет, а автозагрузка приложений при логине юзверя делается проще.

но дёргать не аппаратными прерываниями, а более высокоуровневыми средствами

Всмысле? А как же IRQ0? А как же HPET? Ты же вроде знаешь ассемблер...

Процессор одноядерный

Я уже и не помню когда это было. Когда я _еще_ играл в игры мне уже приходилось ставить старым играм Thread Affinity на одно ядро, а я _уже_ не играю в игры пожалуй несколько лет.

Многозадачность в винде с 95-го года вытесняющая.

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

поток вторичный,

Нет вторичных потоков. Есть фоновые (BACKGROUND).

Если приоритеты потоков не достаточно разнообразны, это проблема не моя, а конкретной оси

Обычно предполагается что когда твой тред получит квант времени он быстро сделает что-то и повиснет на объекте синхронизации или ожидании ввода-вывода. И ОС поместит ядро процессора в состояние останова до следующего прерывания, что позволит его охладить. Приоритет это хотелка. ОС имеет право не принимать ее во внимание. Windows, например, жульничает в пользу активных пользовательских программ чтобы достигнуть лучшей отзывчивости интерфейса. Реалтаймовая ОС может временно поднять до максимума приоритет фонового потока пока он удерживает ресурс нужный более высокоприоритетному треду (priority inversion).

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