none
Может ли поток монопольно захватить процессор? RRS feed

  • Общие обсуждения

  • Среди функций Kernel-mode API есть средства, позволяющие назначить потоку определенный процессор (в многопроцессорной системе). Можно ли сделать так, чтобы поток владел этим процессором монопольно (т.е. другие потоки не выполнялись на нем, пока данный поток не завершится)?
    13 января 2016 г. 18:10

Все ответы

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

    Если сообщение помогло Вам, пожалуйста, не забудьте отметить его как ответ данной темы. Удачи в программировании!

    13 января 2016 г. 20:41
  • Это в том числе касается и драйверов режима ядра?
    14 января 2016 г. 7:16
  • Это в том числе касается и драйверов режима ядра?

    Это касается любого кода, исполняемого под управлением Windows.

    Если сообщение помогло Вам, пожалуйста, не забудьте отметить его как ответ данной темы. Удачи в программировании!

    14 января 2016 г. 7:41
  • В принципе, вытесняющая многозадачность на время отключается установкой для потока Irql = DISPATCH_LEVEL. Но, к сожалению, эффект распространяется на всю систему. Нет ли другого средства с похожим эффектом, но с возможностью ограничить его одним ядром процессора?
    • Изменено Alex______ 14 января 2016 г. 8:00
    14 января 2016 г. 8:00
  • Мне кажется, что в решении своей задачи Вы двигаетесь не в том направлении. Не нужно искусственно вмешиваться в планирование потоков и распределение процессорных ядер (с этим прекрасно справляется ОС). Нужно грамотно организовать синхронизацию потоков, тогда, действительно, ни один поток не помешает выполнить важные для Вас действия.

    Если сообщение помогло Вам, пожалуйста, не забудьте отметить его как ответ данной темы. Удачи в программировании!

    14 января 2016 г. 9:02
  • Я пытаюсь реализовать на Windows алгоритм реального времени. Требуется выполнять некоторые действия с периодом порядка 10 мкс. Все имеющиеся средства синхронизации Windows оперируют интервалами времени на несколько порядков больше, не говоря уже о точности. Этот путь, будь он возможен, позволил бы - пусть ценой уменьшения производительности системы в целом и роста энергопотребления - добиться результата. Других способов не вижу. Буду очень признателен, если вы сможете их подсказать.
    • Изменено Alex______ 14 января 2016 г. 13:47
    14 января 2016 г. 13:19
  • Я пытаюсь реализовать на Windows алгоритм реального времени.

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

    Поясните свою задачу, может что-то и придет на ум.


    Если сообщение помогло Вам, пожалуйста, не забудьте отметить его как ответ данной темы. Удачи в программировании!

    14 января 2016 г. 19:38
  • Общение с оборудованием далеко не всегда сводится к обработке прерываний. В данном случае, к примеру, речь идет об управлении шаговым двигателем, для чего необходимы импульсы достаточно высокой частоты. Мне известно, к примеру, что разработчики программ Mach3/Mach4 эту задачу решили, и я примерно представляю, каким способом - через подмену обработчика прерываний системного таймера и изменение его настроек. Данный способ имеет недостатки - он сложен и может требовать модификаций кода для каждой версии Windows. К тому же антивирусные средства (встроенные и дополнительные) воспринимают это как взлом системы, и программа может неожиданно перестать работать после установки очередного обновления от Microsoft (если только данный конкретный код с Microsoft не согласован). Мне бы очень не хотелось ввязываться в такую историю.
    14 января 2016 г. 20:02
  • Скорее всего либо игнорированием проблемы (так как обычно важно число шагов, а не стабильность частоты шагов), либо же использованием любого микроконтроллера.

    Компьютер просто говорит контроллеру куда/как крутить двигатель (считывать данные, зажигать лампочки и т.п.), и контроллер делает. ОС на контроллере нет, все под полным контролем программиста. 

    Железо в любом случае надо как то подключать, почему не использовать дешевые контроллеры с подключением по USB, например семейства Аrduino.


    This posting is provided "AS IS" with no warranties, and confers no rights.

    14 января 2016 г. 20:47
    Модератор
  • Да нет же. Речь идет о выдаче импульсов через порт LPT. И нужна плавная и точная регулировка скорости вращения, то есть частоты импульсов. Я давно занимаюсь программированием таких систем под QNX. Но эти ребята получили такой же результат под Windows - они программным путем, без всякого дополнительного оборудования, выдают на выходы обычного встроенного LPT импульсы с частотой 25 кГц. Как, по-вашему, они это делают?
    14 января 2016 г. 21:32
  • Я именно об этом: ну кто сейчас использует порт LPT? Ну ладно еще в начале 90х с повальной бедностью и отсутствием доступных компонентов...

    Но сегодня его во многих случаях просто нет. И все равно нужно железо для управления двигателем, по крайней мере ключи. С тем же успехом можно использовать китайские ардвино, по цене примерно как разъем для принтерного порта. Зачем использовать суррогаты когда есть правильные инструменты по доступной цене?

    Очень просто: имеют цикл со слипами где переключают биты. Если на поток дать приоритет реального времени, то в большинстве случаев все будет работать без всяких проблем даже на ОС которая не гарантирует время реакции. Редкие пропуски заметить будет практически невозможно. 


    This posting is provided "AS IS" with no warranties, and confers no rights.

    14 января 2016 г. 22:09
    Модератор
  • Еще раз, по пунктам, медленно:
    1). Конфигурация железа в данном случае не является предметом обсуждения - так поставлена задача, поставлена не мною и я на это влиять не могу.
    2). Относительно цикла со слипами: Вы прочитали про частоту 25 кГц? Это соответствует периоду 40 микросекунд, или интервалу 20 микросекунд между переключениями битов с 0 на 1 и обратно. Я буду Вам весьма признателен, если Вы расскажете мне, какие средства Windows позволяют программировать задержки такой величины, безразлично, на уровне пользовательской задачи или ядра, на приоритете обычном, повышенном или реального времени.



    • Изменено Alex______ 14 января 2016 г. 22:50
    14 января 2016 г. 22:22
  • Это между вами и заказчиком. Следует по меньшей мере объяснить какие проблемы могут возникнуть с данным выбором (а их великое множество от поиска порта до подписи драйвера на 64 битной ОС).

    В начале 90х я на быстрой 286 (16 MHz 0WS) я захватывал видео через параллельный порт с использованием нескольких компараторов. Получалась частота примерно 500-700 KHz вместе с выводом на экран, было даже что то видно. Синхроимпульсы обрабатывались программно.

    Примерно в те же времена популярная программа для синтеза звука использовала ЦАП на параллельном порту без всяких буферов. Умудрялась не только выводить самплы с приличной частотой (22 КHz что ли), но еще и собственно музыку синтезировать.

    Конечно все это было под DOS, но если принять во внимание что производительность компьютеров выросла по меньшей мере в 1000 раз то 25KHz вовсе не кажутся такими страшными.

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


    This posting is provided "AS IS" with no warranties, and confers no rights.

    14 января 2016 г. 23:10
    Модератор
  • Простой калиброванный цикл задержки вполне сойдет.

    Полностью согласен (в случае использования LPT, разумеется). Хотя, это, действительно, "средневековье" и дополнительный микроконтроллер решил бы все проблемы.

    Если сообщение помогло Вам, пожалуйста, не забудьте отметить его как ответ данной темы. Удачи в программировании!

    15 января 2016 г. 5:57
  • 1. Разумеется, при использовании DOS у меня не возникло бы вопросов.
    2. Разумеется, цикл задержки - это первое, что я попробовал. Но периодически возникающие пропуски длиной в 10-20 тактов меня не устраивают - это приводит к ощутимым нарушениям в работе оборудования. Насколько я понимаю, нет абсолютно никакой гарантии и от бОльших пропусков.
    3. Поэтому у меня и возник исходный вопрос.

    15 января 2016 г. 7:09
  • Возникли бы скорее всего, особенно с учетом производительности железа в те времена. Под ДОС тоже были прерывания. Запрет был обычно не вариант, прекращали работу часы и клавиатура.

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


    This posting is provided "AS IS" with no warranties, and confers no rights.

    15 января 2016 г. 17:19
    Модератор
  • Ну да. "Нет хлеба - пусть едят пирожные".
    Разумеется, все, что Вы написали, справедливо. Разумеется также, что все это не имеет прямого отношения к моему вопросу. Последний раз, по пунктам, просто уже из любви к искусству:
    1. Есть конкретная задача.
    2. Есть конкретный выбор аппаратной и программной платформы.
    3. Есть убедительные данные, что решение этой задачи на этой платформе (возможно, не идеальное, возможно, не самое рациональное) существует.
    4. Есть вопрос: каким способом оно может быть достигнуто?
    Все ответы экспертов в этой ветке переводятся на обычный человеческий язык двумя словами: "Не знаю".
    Спасибо. Я примерно так и предполагал.
    15 января 2016 г. 17:46
  • Пожалуйста. Если бы это решение знал каждый, разработчики Mach не продавали бы свой "шедевр", а раздавали его бесплатно. Удачи.

    Если сообщение помогло Вам, пожалуйста, не забудьте отметить его как ответ данной темы. Удачи в программировании!

    15 января 2016 г. 18:24
  • Добрый день,

    Есть конкретный выбор аппаратной и программной платформы.

    Если вы не можете что-то сделать, значит выбор был не верным.

    Прочитав всю ветку понял две вещи:

    1. Вы должны уяснить, что windows и операции реального времени с аппаратным железом не совместимы по определению.

    2. Вам уже посоветовали посмотреть в сторону Arduino(или другой аналогичной платформы для прототипирования), как я понял даже эта микруха(Atmega328p) справится с вашими задачами.

    При простом программировании на чистом С скорость IO портов Arduino разгоняется до 2.667Мгц - Faster IO on the Arduino

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

    3. Самый лучший путь уменьшения латентности - переход от цифры к аналоговым сигналам, но тут уже необходимы соответствующие знания, зато получим настоящий real time!


    16 января 2016 г. 14:40
  • Смотрите Теорию автоматического управления часть первая - линейные стационарные системы.
    16 января 2016 г. 15:09
  • Не надо мне объяснять, что дважды два - четыре, а Волга впадает в Каспийское море. Я задал конкретный вопрос и рассчитывал на конкретный ответ, а вовсе не на демонстрацию широты Вашей эрудиции и глубины Ваших познаний, в которых я и без того заранее уверен.
    16 января 2016 г. 20:18
  • Я думаю что лучше поставить между LPT портом и шаговым двигателем какой то контроллер которому отправлять команды, а уже он будет подавать импульсы с нужной частотой в реальном времени на двигатель. Думаю Mach так и делает.

    17 января 2016 г. 4:36
  • Написали низкоуровневый драйвер, которому подают команды из обычной программы.
    17 января 2016 г. 4:38
  • Вам поможет только написание драйвера
    17 января 2016 г. 4:41
  • Я вообще-то и спрашивал о возможностях, которыми мог бы воспользоваться при написании драйвера. Потому что в документации по функциям режима ядра не нашел того, что могло бы мне помочь.
    17 января 2016 г. 13:39