Дизайн: Task-Asynchronous Pattern (TAP с await / async), против потоков с сигнализацией против других структур потоков

Question

Дизайн: Task-Asynchronous Pattern (TAP с await / async), против потоков с сигнализацией против других структур потоков

1

Было бы с благодарностью принята помощь с идеями о редизайне ниже программы С#. Я пытаюсь выбрать между реализацией многопоточности, используя 1) TAP, 2) потоки конечных потоков, которые содержат прядильщики, которые заканчиваются, когда их bools установлены в false, или 3) одни и те же потоки с использованием сигнализации вместо этих bools. Я объясню нижеприведенную программу, чтобы сделать это ясно.

Программа

Программа - приложение для автоматизации игры на С#, которое я разрабатываю как интересный способ изучения языка, а функции С# (5.0) лучше. Он имеет пользовательский интерфейс, который должен оставаться отзывчивым во время работы приложения.

Когда открывается отдельная вкладка в пользовательском интерфейсе, программа запускает новый поток под названием "Сканирование", который в новом методе в другом классе сканирует различные ячейки памяти и обновляет метки в пользовательском интерфейсе с помощью этих быстро изменяющихся значений с помощью интерфейса синхронизации SyncContext, Это продолжается в течение (сканирующего) цикла, пока сканирование bool истинно (как правило, полная продолжительность жизни программы).

Когда пользователь нажимает кнопку "Пуск" на этой вкладке, программа запускает два новых потока, которые выполняют следующие действия: "Прогон" перемещает символ вокруг по определенному пути. Тема "Действие" нажимает определенные кнопки и выполняет действия одновременно с тем, как игрок запускает путь. Если возникает определенный сценарий, программа должна временно приостановить поток и поток действий, запустить метод, а когда он закончится, вернитесь к запуску и действию.

Когда пользователь нажимает кнопку "Стоп" на этой вкладке, автоматизация должна останавливаться, и потоки завершаются.

Соревнование

Я уже создал рабочую версию, используя непрерывные циклы сглаживания в каждом потоке, который заботится о различных работах. Прокручиватели работают с помощью while (myBool). Для трех потоков: bools: сканирование, запуск и действие.

Когда я хочу остановить поток, я устанавливаю bool в false и использую Thread.Join, чтобы ждать, пока поток завершится изящно, прежде чем продолжить. Потоки могут, как упоминалось, останавливаться пользователем, нажав кнопку "Стоп", или автоматически программой в рамках ее функциональности. В последнем случае поток останавливается, присоединяется, а затем на более позднем этапе перезапускается.

Проделав много чтения и исследований по потоковому использованию и новым инструментам асинхронного программирования на С# 5.0, я понял, что способ, которым я в настоящее время это делаю, может быть очень неуклюжим и непрофессиональным. Он создает множество проблем с синхронизацией/потоковой безопасностью, и поскольку цель всего этого состоит в том, чтобы узнать больше о С#, я хотел бы принять ваше решение о том, следует ли мне изменить его на мелкозернистый асинхронный подход к программированию, используя TAP с асинхронно и ждать по мере необходимости.

Это похоже на случай, когда могут быть полезны задачи с маркерами отмены? Потоки после всех длительных операций, поэтому я был обеспокоен тем, что использование пула потоков (Task.Run) приведет к плохой гигиене в пуле потоков (чрезмерной подписке). Если асинхронное программирование похоже на плохое совпадение здесь, как об использовании потоков, как я это сделал, но вместо этого используйте сигнализацию для запуска и остановки потоков?

Любые мысли очень оценили.

Anders 12 окт. 2014, в 17:16

Источник

0

Рассматривали ли вы использование TPL DataStream или ReactiveExtensions? Оба предназначены для одновременной и / или асинхронной передачи данных.
Aron 10 фев. 2017, в 08:54

Теги:

c#

multithreading

async-await

asynchronous

unmanaged

1 ответ

Ещё вопросы

Рассматривали ли вы использование TPL DataStream или ReactiveExtensions? Оба предназначены для одновременной и / или асинхронной передачи данных.

jgauffin · Answer 1 · 2014-10-12T17-36-00.000Z

0

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

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

Но для других это трудно понять. Они работают постоянно или периодически? Если они все время работают, вы должны держать их в отдельных потоках.

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

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

public void ActionRunnerThreadFunc()
{
    _drawQueue.Enqueue(new SpaceShipRenderer(x, y));
}

public void UIThreadFunc()
{
    IItemRender item;
    if (_drawQueue.TryDequeue(out item))
        item.Draw(drawContext);
}

jgauffin 12 окт. 2014, в 17:36

0

Спасибо за ответ J. Приложение на самом деле не игра, а скорее инструмент, который автоматизирует игровой процесс (поэтому перемещает персонажа и выполняет различные задачи, без взаимодействия с человеком). Я думал, что задачи кажутся полезными, так как они могут иметь тип возврата, а также предлагают возможность прикреплять продолжения (либо явно с помощью awaiter, либо неявно через ключевое слово await ). Поэтому я думаю, что вы правы, что сканер памяти должен просто работать в отдельном потоке и может использовать ManualResetEvent.WaitOne вместо bool сканера. (продолжение в следующем комментарии)
Anders 12 окт. 2014, в 20:37
0

Но для двух других потоков: они не работают вечно. Скажем, что я хочу сделать, это рубить деревья. Таким образом, в одном потоке персонаж бегает по заданному пути. Другой поток, который работает параллельно, постоянно нажимает кнопку для поиска деревьев. Как только дерево найдено, оба этих потока должны временно остановиться, и должен начаться метод treeChopping. Когда дерево завершит рубку, игрок должен вернуться к бегу по дорожке в поисках деревьев. Такое ощущение, что три задачи будут хорошо работать здесь, верно?
Anders 12 окт. 2014, в 20:41
0

Если вырубка дерева завершится через секунду, я бы запустил его в задании. Иначе я бы держал это в отдельном потоке.
jgauffin 13 окт. 2014, в 06:39
0

Но как насчет использования TaskCreationOptions.LongRunning, чтобы избежать пула потоков? Какова причина, чтобы не использовать задачи здесь, вы думаете?
Anders 13 окт. 2014, в 20:44
0

«Принцип наименьшего удивления».
jgauffin 13 окт. 2014, в 21:32
0

Понятно, но что касается этого принципа, рубка дерева действительно кажется задачей, не так ли? То же самое с задачей поиска деревьев и задачей прохождения пути, пока дерево не будет найдено. Тип возвращаемых данных и токены отмены пригодятся. Представьте себе, что нет bools для остановки циклов вращения (просто передайте токен отмены в задачу), и задача рубки дерева (в качестве примера) может вернуть строку, на которую может ответить продолжение (например, с помощью оператора switch). Мне однажды сказали, что многие старые методы потоков (Join / Sleep и т. Д.) Устарели теперь, когда у нас есть основанная на задачах асинхронность. Может быть неправильно
Anders 13 окт. 2014, в 21:46
0

-1 Этот ответ, кажется, смешивает и смешивает несколько технологий. TAP! = TPL! = Task.Run! = ThreadPool.Enqueue . Основным преимуществом использования TAP является то, что TAP - это богатый API с мощной структурой (такой как TPL) для его резервного копирования. Сам TAP - это просто набор (псевдо) интерфейсов, для которых существует множество реализаций. Основное преимущество использования TAP состоит в том, что вы можете перемещаться между реализациями с помощью общего набора методов (полиморфизм).
Aron 10 фев. 2017, в 08:48
0

Ваш ответ читается так, как будто вы объясняете wss websockets кому-то, кто спрашивал о ethernet.
Aron 10 фев. 2017, в 08:50
0

Если вы используете Google «TAP C #», первая статья MSDN будет иметь название «Асинхронное программирование на основе задач», а в первом абзаце рассказывается о TPL. С точки зрения этого вопроса, эта связь просто прекрасна, так как OP спрашивает, должен ли он вместо этого использовать явные потоки или TAP. Мой первый абзац пытается объяснить, что использование задач для долгоживущих задач (без дополнительных задач внутри них) эффективно заставит планировщик задач использовать больше потоков. В этом смысле длительно выполняемые операции, связанные с процессором, не приносят пользы, если их обернуть в задачу вместо собственного потока.
jgauffin 10 фев. 2017, в 10:49
0

Я не согласен с тем, что «ОСНОВНОЕ преимущество использования TAP состоит в том, что вы можете перемещаться между реализациями с помощью общего набора методов (полиморфизм)». , Чтобы заявить о преимуществах, вы должны сравнить с чем-то, а APM - другая модель в .NET. TAP дает вам гораздо больше по сравнению с APM. Моими двумя основными причинами использования TAP является то, что код гораздо проще поддерживать, так как планировщик задач + удаляет много сантехники. (или EAP async решается в классах сокетов)
jgauffin 10 фев. 2017, в 10:52

Показать ещё 8 комментариев