C# continuazione di prima classe tramite l'interoperabilità C++ o in un altro modo?

Question

Abbiamo un multitasking ad alte prestazioni, vicino all'applicazione C# in tempo reale. Questa performance è stata ottenuta principalmente implementando il multitasking cooperativo internamente con uno scheduler nazionale. Questo è spesso chiamato micro-thread. In questo sistema tutte le attività comunicano con altre attività tramite le code.

Il problema specifico che abbiamo sembra essere risolvibile solo tramite continuazioni di prima classe che C# non supporta.

In particolare, il problema si pone in 2 casi relativi alle code. Ogni volta che una determinata attività esegue del lavoro prima di posizionare un oggetto su una coda. Cosa succede se la coda è piena?

Al contrario, un'attività diversa può richiedere un po 'di lavoro e quindi è necessario rimuovere un elemento da una coda. Cosa succede se quella coda è vuota?

Abbiamo risolto questo problema nel 90% dei casi collegando le code alle attività per evitare che le attività vengano richiamate se una delle loro code in uscita è piena o la coda in ingresso è vuota.

Inoltre alcune attività sono state convertite in macchine a stati in modo che possano gestire se una coda è piena/vuota e continuare senza attendere.

Il vero problema si pone in alcuni casi limite in cui non è pratico fare una di queste soluzioni. L'idea in questo scenario sarebbe quella di salvare lo stato di stack nel punto e passare a un'attività diversa in modo che possa eseguire il lavoro e successivamente riprovare l'attività di attesa ogni volta che è in grado di continuare.

In passato, abbiamo tentato di richiamare l'attività in attesa nella pianificazione (in modo ricorsivo) per consentire alle altre attività di riprendere in seguito l'attività in attesa. Tuttavia, ciò ha portato a troppe situazioni di "stallo".

C'è stato un esempio da qualche parte di un host CLR personalizzato per fare in modo che i thread .NET funzionino come "fibre" che essenzialmente consente di cambiare lo stato di stack tra i thread. Ma ora non riesco a trovare alcun codice di esempio per questo. Inoltre sembra che ci vorrà una certa complessità per farlo bene.

Qualcuno ha altre idee creative su come passare tra le attività in modo efficiente ed evitare i problemi di cui sopra?

Ci sono altri host CLR che offrono questo, commerciale o altro? C'è qualche libreria nativa aggiuntiva che può offrire qualche forma di continuazione per C#?

Answer 1

In realtà, abbiamo deciso una direzione per andare con questo. Stiamo usando il pattern Observer con Message Passsing. Abbiamo costruito una libreria nazionale per gestire tutte le comunicazioni tra "agenti" simili a un processo di Erlang. In seguito prenderemo in considerazione l'utilizzo di AppDomains per separare gli agenti ancora meglio l'uno dall'altro. Le idee di progettazione sono state prese in prestito dal linguaggio di programmazione di Erlang che ha un'elaborazione multintegrale e distribuita estremamente affidabile.

Answer 2

La soluzione al problema consiste nell'utilizzare algoritmi lock-free che consentono l'avanzamento a livello di sistema di almeno un'attività. È necessario utilizzare un assemblatore in linea dipendente dalla CPU per accertarsi che sia CAS atomico (confronta e scambia). Wikipedia ha uno article e modelli descritti lo book di Douglas Schmidt chiamato "Architettura del software orientata al pattern, Pattern per oggetti concatenati e in rete". Non mi è immediatamente chiaro come lo farete sotto il framework dotnet.

Un altro modo per risolvere il problema è utilizzare il modello di sottoscrizione di pubblicazione o possibili pool di thread.

Spero che questo sia stato utile?

Answer 3

C'è la C# 5 CTP, che esegue una trasformazione-passing-style continuazione rispetto ai metodi dichiarati con il nuovo async parola chiave, e le chiamate in base continuazione-passing quando si utilizza la parola chiave await.

Questa non è in realtà una nuova funzionalità CLR, ma piuttosto una serie di direttive per il compilatore per eseguire la trasformazione CPS sul codice e una manciata di routine di libreria per la manipolazione e la pianificazione delle continuazioni. I record di attivazione per i metodi async vengono posizionati nell'heap anziché nello stack, quindi non sono collegati a un thread specifico.

Answer 4

No, non funzionerà. C# (e anche IL) è un linguaggio troppo complesso per eseguire tali trasformazioni (CPS) in modo generale. Il meglio che puoi ottenere è ciò che C# 5 offrirà. Detto questo, probabilmente non sarai in grado di rompere/riprendere con cicli/iterazioni di ordine superiore, il che è veramente quello che vuoi da continuazioni reifiable per scopi generali.

Answer 5

modalità Fiber è stato rimosso dalla v2 del CLR a causa di problemi in condizioni di stress, vedi:

• Fiber mode is gone...
• Fibers and the CLR
• Question to the CLR experts : fiber mode support in hosting

Per il mio supporto in fibra di conoscenza non ha ancora l'ape è stata aggiunta nuovamente, anche se dalla lettura degli articoli di cui sopra è possibile aggiungere nuovamente (h Tuttavia, il fatto che nulla sia stato menzionato per 6-7 anni sull'argomento mi fa pensare che sia improbabile).

supporto proposito fibra è stato destinato ad essere un modo per applicazioni che utilizzano fibre (ad esempio SQL Server) per ospitare il CLR in un modo che permette loro di massimizzare le prestazioni esistente, non come un metodo per consentire Applicazioni di rete per creare centinaia di thread - in fibre corte non è una soluzione magica per il tuo problema, tuttavia se hai un'applicazione che utilizza fibre desideri ospitare il CLR, allora le API di hosting gestite forniscono i mezzi per il CLR a " funziona bene "con la tua applicazione. Una buona fonte di informazioni su questo sarebbe il managed hosting API documentation, o per esaminare come SQL Server ospita il CLR, di cui ci sono diversi articoli altamente informativi in ​​giro.

Leggere anche Threads, fibers, stacks and address space.