none
C# .Net Core БЫстрый доступ с конкуренцией за доступ к разделяемому ресурсу

    Вопрос

  • Добрый вечер!

    Правильно ли я понимаю, что чем больше потоков с высоким приоритетом конкурируют за доступ к одному из ресурсов, тем выше вероятность, что ОС быстрее предоставит одному из потоков доступ к этому ресурсу?

    Заранее благодарен за ответы.

    13 сентября 2018 г. 17:34

Ответы

  • Читает данные из другого сервиса и отображает на экране.

    Для этого не требуется высокого приоритета. Содержимое экрана все равно больше ~60 раз в секунду не обновить. Да и вообще, люди очень медленные. Даже старинные компьютеры с производительностью в сотню тысяч операций в секунду без особых проблем обслуживали с полдюжины человек.

    Вот когда будете писать программу для управления полетом гиперзвуковой ракеты, вот тогда вам _может быть_ потребуется подстройка приоритета потоков. :)

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


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

    • Помечено в качестве ответа _Alex9_ 17 ч. 48 мин. назад
    14 сентября 2018 г. 19:51
  • Упрощенно говоря, потоку с приоритетом реального времени ОС всегда выделяет столько процессорного времени, сколько он запрашивает, в обход обычных правил планировщика (в том числе, за счет выделения меньшего времени потокам самой ОС). Если такой поток потребляет слишком много процессорного времени, работа системы может быть полностью парализована, поэтому они применяются только для специфических задач, с малыми вычислительными затратами, но с необходимостью выполнения их с минимальной задержкой. Например, обработка звука.

    Конкретные детали зависят от ОС (Net Core работает на многих, с довольно разной архитектурой ядра). Обычно управляемые приложения, что Net, что Net Core, не должны использовать приоритет реального времени, так как они слишком тяжелы и не подходят для задач, в которых это имеет смысл.

    • Помечено в качестве ответа _Alex9_ 17 ч. 48 мин. назад
    18 ч. 25 мин. назад

Все ответы

  • Думаю что вероятность что ОС предоставит доступ одному из потоков не зависит от их числа и всегда составляет 100%. В самом деле, если ресурс свободен, то доступ будет предоставлен немедленно, а если занят то доступ уже предоставлен другому потоку.

    Ну а как быстро это произойдет будет определяться числом потоков, средней частотой доступа к ресурсу и средним временем захвата ресурса. 


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

    13 сентября 2018 г. 18:44
  • То есть 1 realtime поток может заменить несколько потоков с нормальным приоритетом? Частоту доступа к ресурсу и время захвата ресурса ОС прогнозирует на основе предыдущего поведения программы?
    14 сентября 2018 г. 5:39
  • То есть 1 realtime поток может заменить несколько потоков с нормальным приоритетом? Частоту доступа к ресурсу и время захвата ресурса ОС прогнозирует на основе предыдущего поведения программы?

    Не может, конечно. Я думаю вы не совсем понимайте что делает и зачем нужен realtime приоритет. Опишите с какой целью вы пытайтесь его использовать и что именно делает приложение.

    Частота доступа к ресурсу и время его захвата целиком определяется кодом программы. Никакого "прогнозирования" нет (и не требуется).  


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

    14 сентября 2018 г. 5:48
  • Читает данные из другого сервиса и отображает на экране.
    14 сентября 2018 г. 18:06
  • Читает данные из другого сервиса и отображает на экране.

    Для этого не требуется высокого приоритета. Содержимое экрана все равно больше ~60 раз в секунду не обновить. Да и вообще, люди очень медленные. Даже старинные компьютеры с производительностью в сотню тысяч операций в секунду без особых проблем обслуживали с полдюжины человек.

    Вот когда будете писать программу для управления полетом гиперзвуковой ракеты, вот тогда вам _может быть_ потребуется подстройка приоритета потоков. :)

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


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

    • Помечено в качестве ответа _Alex9_ 17 ч. 48 мин. назад
    14 сентября 2018 г. 19:51
  • Возможно автор спрашивает про сервис типа синглтон, с длительной обработкой запроса. И как правильно организовать запрос с клиента, чтоб его запросы имели приоритет над другими клиентами, которые уже стоят в очереди.
    15 сентября 2018 г. 5:38
  • Возможно автор спрашивает про сервис типа синглтон, с длительной обработкой запроса. И как правильно организовать запрос с клиента, чтоб его запросы имели приоритет над другими клиентами, которые уже стоят в очереди.

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

    Кстати, singleton этому не мешает (хотя его следует избегать по другим причинам как то сильная привязка фрагментов кода и проблемы с тестированием).


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

    15 сентября 2018 г. 6:03
  • Если так то автору надо переделать сервис чтоб у него была явная очередь или, лучше, чтоб сервис мог обрабатывать несколько запросов сразу, каждый на своем потоке.


    Если автор не может влиять на код серверной части, но у него есть спецификации контракта и он хочет написать клиента, который бы имел преимущества над уже существующими клиентскими приложения, разработанные другими специалистами. Что можно использовать в таком случае и какую информацию посоветуете к изучению. На сколько я помню автор топика очень любит теорию.
    15 сентября 2018 г. 6:34
  • Если так то автору надо переделать сервис чтоб у него была явная очередь или, лучше, чтоб сервис мог обрабатывать несколько запросов сразу, каждый на своем потоке.


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

    Если автор не может влиять на код серверной части, то манипуляция приоритетом потоков _на клиенте_ никак ему не поможет. 

    В любом случае, предоставим автору описать систему в деталях вместо того чтоб строить догадки.


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

    15 сентября 2018 г. 6:43
  • Вместо решения чужих проблем, когда об этом не просят, предлагаю вместе разобраться с тем, что же такое realtime-потоки, и с чем их едят.
    17 сентября 2018 г. 16:59
  • Упрощенно говоря, потоку с приоритетом реального времени ОС всегда выделяет столько процессорного времени, сколько он запрашивает, в обход обычных правил планировщика (в том числе, за счет выделения меньшего времени потокам самой ОС). Если такой поток потребляет слишком много процессорного времени, работа системы может быть полностью парализована, поэтому они применяются только для специфических задач, с малыми вычислительными затратами, но с необходимостью выполнения их с минимальной задержкой. Например, обработка звука.

    Конкретные детали зависят от ОС (Net Core работает на многих, с довольно разной архитектурой ядра). Обычно управляемые приложения, что Net, что Net Core, не должны использовать приоритет реального времени, так как они слишком тяжелы и не подходят для задач, в которых это имеет смысл.

    • Помечено в качестве ответа _Alex9_ 17 ч. 48 мин. назад
    18 ч. 25 мин. назад