Шаблон проектирования, альтернатива сопрограммам

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

Рассмотрим метод

IEnumerable Thread ()
{
    //do some stuff
    Foo ();

    //co-operatively yield
    yield null;

    //do some more stuff
    Bar ();

    //sleep 2 seconds
    yield new TimeSpan (2000);
}

Компилятор C# развернет это в конечный автомат, но внешний вид будет похож на кооперативный микропоток.

Схема довольно проста. Вы реализуете «планировщик», который хранит список всех активных IEnumerators. Когда он циклически проходит по списку, он «запускает» каждый из них, используя MoveNext(). Если значение MoveNext равно false, поток завершен, и планировщик удаляет его из списка. Если это правда, то планировщик обращается к свойству Current, чтобы определить текущее состояние потока. Если это TimeSpan, поток хочет заснуть, и планировщик переместил его в некоторую очередь, которую можно сбросить обратно в основной список, когда промежутки времени ожидания закончились.

Вы можете использовать другие возвращаемые объекты для реализации других механизмов сигнализации. Например, определите какой-нибудь WaitHandle. Если поток выдает один из них, он может быть перемещен в очередь ожидания до тех пор, пока дескриптор не будет сигнализирован. Или вы можете поддержать WaitAll, создав массив дескрипторов ожидания. Вы даже можете реализовать приоритеты.

Я сделал простую реализацию этого планировщика примерно за 150LOC, но еще не успел опубликовать код в блоге. Это было для нашей оболочки PhyreSharp PhyreEngine (которая не будет общедоступной), где, похоже, она неплохо работает для управления парой сотен персонажей в одной из наших демонстраций. Мы позаимствовали эту концепцию из движка Unity3D — у них есть несколько онлайн-документов, которые объясняют ее с точки зрения пользователя.

.NET 4.0 поставляется с расширенной поддержкой параллелизма задач. :

• Как использовать Parallel.Invoke для выполнения простых параллельных задач
• Как вернуть значение из задачи
• Как объединить несколько задач с продолжением

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

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

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

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

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

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

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

Надеюсь, это имеет смысл!

PS: Есть ли у вас зависимости от порядка задач?

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

Разве это не обычное использование многопоточной обработки?

Ознакомьтесь с такими шаблонами, как Reactor здесь

Может быть достаточно написать его для использования асинхронного ввода-вывода. .

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

Вы должны взглянуть на это:

http://www.replicator.org/node/80

Это должно делать именно то, что вы хотите. Однако это взлом.

Еще немного информации о шаблоне «Реактивный» (как упоминалось другим автором) в отношении реализации в .NET; также известный как «Связь с событиями»

http://themechanicalbride.blogspot.com/2009/07/introduction-rx-linq-to-events.html

-Ойсин

На самом деле, если вы используете один поток для задачи, вы проиграете игру. Подумайте, почему Node.js может поддерживать огромное количество соединений. Использование нескольких потоков с асинхронным вводом-выводом!!! В этом могут помочь функции Async и await.

foreach (var task in tasks)
{
    await SendAsync(task.value);
    ReadAsync(); 
}

SendAsync() и ReadAsync() — это поддельные функции для асинхронного вызова ввода-вывода.

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

Да, конечно ты можешь. Вам просто нужно создать диспетчерский механизм, который будет вызывать предоставленную вами лямбду и ставить ее в очередь. Весь код, который я пишу в Unity, использует этот подход, и я никогда не использую сопрограммы. Я оборачиваю методы, которые используют сопрограммы, такие как WWW, чтобы просто избавиться от них. Теоретически сопрограммы могут быть быстрее, потому что меньше накладных расходов. Практически они вводят новый синтаксис в язык для выполнения довольно тривиальной задачи, и, кроме того, вы не можете правильно отследить трассировку стека при ошибке в сопрограмме, потому что все, что вы увидите, это ->Next. Затем вам нужно будет реализовать возможность запуска задач в очереди в другом потоке. Однако в последней версии .net есть параллельные функции, и вы, по сути, будете писать аналогичные функции. На самом деле это не будет много строк кода.

Если кому интересно, вышлю код, не носите его с собой.