Erlang-Stil leichte Prozesse in .NET

Ich denke, der F # MailboxProcessor ist genau das, wonach Sie suchen. Mit dem MailboxProcessor können Sie Zehntausende von Agenten innerhalb eines .NET-Prozesses definieren, ähnlich wie Sie in Erlang Zehntausende leichter Prozesse generieren können.

Dies MSDN Post von Don Syme ist eine großartige Einführung.

Wenn Sie von einem Erlang-Hintergrund zu .NET kommen, denken Sie daran, dass Ihnen viele OTP-Goodies fehlen (Supervisoren, Standorttransparenz, Mnesia, ...).

Die CLR kann gehostet werden und macht Mechanismen verfügbar, damit der Host seine eigene Aufgabenabstraktion implementieren kann. Theoretisch können sie Threads, Fasern, LWPs sein - alles, solange der Host das notwendige implementiert Schnittstellen .

Es richtig zu machen ist etwas schwierig. MS nahm eine Chance, um die CLR im SQL Server Fiber Mode zu hosten.

Im letzten Moment gab es einige Stress-Bugs, also zogen sie den Stecker nach Joe Duffy und Dino Vhieland (der ein Serie über das Schreiben eines benutzerdefinierten CLR-Host, der seine eigene Aufgabe Abstraktion implementiert - mit Fasern - auf seinem Blog ).
Im Moment fehlt noch ein paar Klempner - ICLRTask::SwitchOut() - und selbst wenn man das schafft, Die gleichen Bugs, die MS bei der Stresstest-Iteration treffen, würden wahrscheinlich auch die abenteuerlustige Seele verfolgen.

Stellen Sie sich einmal vor, dass alle Probleme irgendwie behoben sind und die gesamte Laufzeit bereit ist, auf Fasern, LWPs oder was auch immer zu laufen. Es gibt immer noch das Problem von P / Invoke, das möglicherweise Blockierungsvorgänge aufrufen könnte. Diese Art der Planung ist ohne Kernel-Unterstützung schwer zu bewerkstelligen.

Dies wird in den 64-Bit-Versionen von Windows 7 und Windows 2008 Server R2 behoben. Es gibt jetzt eine Benutzermodus-Planung , die die Kontrolle zurück auf ein user-mode - im Gegensatz zum Kernel-Modus - Scheduler, wenn ein Aufruf im Kernel blockiert. Diese geplanten Threads im Benutzermodus sind echte Threads mit einem eigenen TLS. Dies sind großartige Verbesserungen und lassen viele Probleme im Fasermodus verschwinden.

Im Moment wird UMS verwendet in der Concurrency-Laufzeit , die für C ++ verfügbar und ist Teil der C-Laufzeitbibliothek (CRT) .
Letzteres bedeutet, dass Sie es direkt mit Visual Studio 2010 verwenden können.

Haben Sie sich reflang angesehen? Ich habe nur darüber gelesen, aber ich habe damit noch nichts gemacht ...

Erlang-Prozess ist wie parallele Methode, aber erlang-Variable kann nur einmal gebunden werden, also ist sie Thread-sicher, die nicht in c # ist.

Sie brauchen also zwei Dinge in c #, threadsicher und parallel.

C # hat System.Threading.Task, Sie können viele Aufgaben in vm ausführen. C # vm plant diese Aufgabe in verschiedenen Arbeitsthreads.

Aber die Aufgabe ist nicht Thread-sicher, Sie müssen eine Klasse namens Actor erstellen und den Status privat in den Actor legen.

Der Actor verfügt über einen System.Threading.SynchronizationContext und viele asynchrone Methoden wie diese.

Wenn andere Akteure die Async-Methode in diesem Actor aufrufen, wird eine Aufgabe erstellt, und die Aufgabe wird von vm geplant.

Sie müssen auch einen erwarteten und Thread-sicheren SynchronizationContext implementieren.

Dies ist ein Thread-sicherer Kontext.

make SynchronizationContext wartebar

Warten auf SynchronizationContext

Dann bekommst du eine Actor-Klasse mit task- und thread-safe, die wie in erlang process ist.

Das ergibt keinen Sinn. "Mehrere Prozesse, die im Kontext eines einzelnen Betriebssystem-Threads oder Betriebssystemprozesses ausgeführt werden" sind logisch nicht eindeutig. Dies ist im Grunde eine logische Anwendungslevel-Sache - die Sie problemlos in .NET reproportieren können. Aber auf Betriebssystemebene gibt es keinen Prozess in einem Prozess.