Волокна в C#: они быстрее, чем итераторы, и люди использовали их?

Итак, я общался с коллегой около fibers и поднял this paper from 2003, в котором описывается реализация сопрограмм в C# с использованием API-интерфейса Fiber.Волокна в C#: они быстрее, чем итераторы, и люди использовали их?

Реализация Yield в данной статье относится к .NET 1.1, поэтому она предшествует синтаксису yield return, который появился в .NET 2.0.

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

Кто-нибудь использовал его?

источник

2009-12-10 Jeremy McGee

Я не использовал его, но у меня есть интерес к теме. Вот одна хорошая реализация сопрограмм в C# с плановым планировщиком: http://www.bluebytesoftware.com/blog/PermaLink.aspx?guid=71235c5a-3753-4bab-bdb0-334ab439afaf – jpbochi

Кстати, какой ответ вы ожидаете этого? – jpbochi

Я его не использовал, но статья была интересной. Проблема в том, что это, похоже, в значительной степени реализовано сейчас, в Windows. –

Кстати, цитируя wikipedia, «волокна описывают по существу ту же концепцию, что и сопрограммы». Насколько я знаю, самое близкое к сопрограмме (или волокну) в C# - итераторы. На самом деле они очень близки к сопрограммам. Lippert опубликовал несколько уловов об итераторах. Надеюсь, ни одна из них не представляет серьезной проблемы для ваших целей.

источник

2009-12-14 16:28:21 jpbochi

Я использовал «сопрограммы», основанные на урожайности, и я должен сказать, что это боль в заднице. Проблема, конечно, в том, что везде, где вы хотите их использовать, вы вынуждены использовать синтаксис yield. Не только это, но если вы не получаете доходности (родительский доход дает доход ребенка), вы можете только когда-либо вложить свои сопрограммы на один уровень в глубину. Это полностью разрушает одно из ключевых преимуществ сопрограммы (полное сохранение/восстановление стека).

Я реализовал волоконно-оптическую систему на C#, и она отлично работала, пока я не ударил исключение. К сожалению, среда исполнения .Net хранит кучу элементов внутреннего исключения в потоках ОС, что означает, что эмуляция нескольких потоков с использованием волокон OS (и p/invoke) просто не будет работать, если у вас никогда не будет исключения.

источник

2010-04-27 15:25:12

Не могли бы вы обойти отсутствие обработки исключений в неуправляемом коде, добавив попытку/уловить каждый кусок управляемого кода до выхода? – Contango

Этот ответ важен. Это означает, что вы никогда не сможете использовать сопрограммы на основе волокон на производстве. – usr

На самом деле это просто означает, что вы должны выполнять свое исполнение, поддерживать обработанные и необработанные исключения, так как вы выполняете, распространяя исключение ТОЛЬКО полностью, когда необработанные. Концепции программирования на основе исключений также должны поддерживаться через концепцию Fiber или подходящую производную. – Jay

Сопрограммы, на очень первый взгляд привлекает мое внимание .. несколько дней назад я искал для решения рабочих процессов для parrallel AsyncWCF методы вызывает и то, что я нашел, был действительно завораживает:

http://csharperimage.jeremylikness.com/2010/03/sequential-asynchronous-workflows-in.html

эта статья показывает очень хорошее использование сопрограмм для создания/управления рабочими процессами в приложении Silverlight, которое использует WCF с использованием Async Pattern.

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

источник

2010-04-27 15:34:25

Волокна в C#: они быстрее, чем итераторы, и люди использовали их?

ответ

Смежные вопросы