Fibre in C #: sono essi più velocemente di iteratori, e hanno gente li usate?

Question

Quindi stavo chiacchierando con un collega su fibre e alzò questo lavoro dal 2003 che descrive una realizzazione di co-routine in C # utilizzando l'API Fiber .

L'attuazione di Yield in questo lavoro è stato per .NET 1.1, precede la sintassi yield return che è apparso in .NET 2.0.

Sembra decisamente, a prima vista, che l'attuazione qui è potenzialmente più veloce e potrebbe scalare su più CPU piuttosto bene.

Qualcuno ha usato?

Answer 1

Non ho usato, ma ho un interesse per l'argomento. Ecco una bella realizzazione di co-routine in C # con uno scheduler round-robin: http://www.bluebytesoftware.com/blog/PermaLink.aspx?guid=71235c5a-3753-4bab-bdb0-334ab439afaf

A proposito, citando wikipedia , "fibre descrivono essenzialmente lo stesso concetto come coroutine". Per quanto ne so, la cosa più vicina ad un coroutine (o fibra) in C # sono iteratori. In realtà, sono notevolmente vicino a coroutines. Lippert pubblicato diversi catture circa iteratori. Si spera, nessuno di loro rappresentano un serio problema per gli scopi necessari.

Answer 2

Ho usato "coroutine," il rendimento di base e devo dire che sono un dolore nel culo. Il problema è, naturalmente, che ovunque si desidera utilizzarli, si è costretti a usare la sintassi rendimento. Non solo, ma a meno che non si concatenano i rendimenti (yield rendimenti genitore del bambino), si può sempre e solo nido tuoi coroutine un livello profondo. Questo distrugge completamente uno dei principali vantaggi di co-routine (stack completo salvataggio / ripristino).

ho implementato un sistema coroutine base di fibre in C # e ha funzionato meravigliosamente FINO ho colpito un'eccezione. Purtroppo il runtime .NET memorizza un mucchio di roba eccezione interna in fili del sistema operativo, il che significa che l'emulazione più thread che utilizzano le fibre del sistema operativo (e P / Invoke) semplicemente non funziona a meno che non avrai mai, mai, mai avuto un'eccezione.

Answer 3

coroutine, al primo sguardo cattura la mia attenzione .. qualche giorno fa ero alla ricerca di soluzione di workflow per Parrallel AsyncWCF chiamate di metodo e quello che ho trovato è stato davvero affascinante:

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

questo articolo mostra un buon uso di coroutine per creare / gestire flussi di lavoro in un'applicazione Silverlight che utilizza WCF utilizzando asincrono modello.

Non so la sua WRT velocità per iteratori ma per me la sua come una forma avanzata di subroutine che può essere molto utile per le attività mission critical, dove una subroutine normale non si può offrire il lusso di svolgere un compito in parallelo.