Mal in Kurzform:
1 Event, mehrere Abonnenten, aber nicht alle sollen das Event verarbeiten. Wer es wann verarbeiten darf, willl ich zur Laufzeit festlegen. Idee?

P.S.: Ich meine ich hab das schonmal gemacht, aber im Moment komme ich nicht drauf. Es liegt vielleicht an der Uhrzeit.

In welcher Welt bist du denn unterwegs. Normale Events? WinForms, WPF?

Bei WPF kannst du das ja beinflussen, indem du im Event ein Property setzt, dass dann das Bubbling stopped.
Stichwort RoutedEvents.

Hilft dir das weiter?

Hallo Rainer,
nein WPF ist es nicht. Ich bastle gerade an einem API für hochgradig parallele und autarke Funktionsobjekte. Die Idee kam mir als ich über "Active Objects" las. Meine Vorstellung davon deckte sich aber nicht mit der Realität. Ich nenne diese Funktionsobjekte zur Zeit "PicoObjects". Diese werden zur Laufzeit aus einer PicoObjectBase generiert. Ein Controller dekoriert ein WorkItem (ein Funktionsblock) mit einem PicoObject (oder umgekehrt? da bin ich noch nicht ganz schlüssig). Dieses Objekt versieht dann selbsttätig seine Aufgabe in einem asynchronen Thread, speichert sein Ergebnis in einer Future-Klasse (wo es dann jederzeit abeholt werden kann), signalisiert seinen Endzustand über ein Event und zerstört sich dann.
Nun sollen diese PicoObjects aber auch in der Lage sein, miteinander zu kommunizieren und sich gegenseitig anzustoßen (Aktionskaskade). Das wollte ich mit Hilfe der erwähnten Events lösen. Falls du dazu eine bessere Idee hast, immer her damit.
Vielleicht ist meine ganze Idee ja auch verrückt.

EDIT: Ich habe gerade im Internet gesehen daß es den Begriff PicoObject schon gibt. DOH!

Sowas hab ich mal in C++ umgesetzt. Gefilterte Events. Die nur durch die Erfüllung einer bestimmten Bedigung ausgeführt wurden.

Schau dir mal die RoutedEvents an von der WPF vielleicht lösen sie schon dein Problem.

Ansonsten meine Idee dazu:

Dabei wären wir auch schon beim Namen: FilteredEvent
Baue dir einen eigenen event (überschreibe das add und remove). Dort nimmst du eine Liste, oder dictionary und füllst eine Bedingung ein. Und beim ausführen wird das Ding nur gefeuert, wenn die beding erfüllt wird).

Frage ist, ob mann bei einem Event das "Fire" überschreiben kann, also den Funktionsaufruf um die Bedingung zu prüfen.

und somit sind wir fertig ... hoffe ich ;-)

Als Alternative Idee hätte ich da noch PostSharp mit dem wir uns in den aufruf reinhängen (einen StaticProxy bauen), oder ein Framework, wie Castle Windsor (mit einem DynamicProxy).

Gute Idee dabei gewesen?

Das klingt alles sehr interessant. Ich werde mich darüber schlau machen und ein paar Tests damit machen. Vielen Dank für diese hilfreichen Tips.

Was hältst du, oder besser gesagt, ihr überhaupt von der Idee dieser autarken Objekte?

Dein Problem ist ja vermutlich, dass zwischen dem Sender und Empfänger des Ereignisses eine Thread-Grenze liegt. Ansonsten hätte dir ja ein einfaches setzen einer WithEvents-Variable schon weitergeholfen (Die gibt es doch in allen .Net sprachen?)

Ich bin ja der Microsoft Welt lange "abtrünig" gewesen, muss aber sagen, dass ich etwas enttäuscht davon bin, was Microsoft in Richtung Multithreading/StateMachines/ActiveObjects unternommen hat ist nicht viel und der Paradigmen-wechsel zur paralellen Verarbeitung steht ja schon bald nicht mehr nur in der Tür.

Ich bin noch nicht in die Verlegenheit gekommen, echtes Multithreading unter DotNet zu realisieren (vom Backgroundworker mal abgesehen) aber wenn ich das richtig sehe, fängt man immer noch bei der guten alten MessageQueue an, nicht. (Die MessageQueue-Komponente, die man sich auf seine Form malen kann ist ja mehr für verteilte Anwendungen als für Multithreading gedacht, wenn ich das richtig sehe?)

Hallo Karle,
ich hab gerade mal in der MSDN-Hilfe nachgesehen, weil "WithEvents" mir vollkommen unbekannt ist. Dieses keyword gibt es unter VB, aber nicht bei C#.

MessageQueue ist in meinem Fall auch nicht anwendbar. Wenn ich das Beispiel in der Hilfe richtig interpretiere, dient dieser Wrapper nur für Nachrichten in Form von Strings. Ich möchte aber Funktionen (bzw Verweise darauf) und Ergebnisse austauschen. Diese Ergebnisse könnten beliebig komplex sein, also z.B. auch eine ganze Entität oder eine Liste. Die spärlichen Infos die ich mir seit Tagen über das Active Object Pattern zusammensuche, sind zudem auch noch lückenhaft. Es scheint aber der richtige Ansatz zu sein.

Ich kann mich auch nur wundern wie stiefmütterrlich die Themen "Active Objects" und "Futures" behandelt werden. Ich sehe da ein sehr großes Potential, gerade in Bezug auf die aktuelle und zukünftige Entwicklung im Parallel Processing.

Die beste Information zu diesem Thema habe ich hiermit gefunden (PDF). Leider ist der Beispielcode in C++.

Ist das nicht mit den 'gefilterten Events' quasi falsch herum, viel zu aufwendig gedacht?

Warum erst ein Event von sehr vielen Objekten verarbeiten lassen, wobei dann die meisten dieser Objekte feststellen, daß sie ohnehin nicht auf diesen Event reagieren sollen?

Es genügt doch, wenn man bsp. irgendeine globale Zuordnungstabelle hat, die sagt: 'Wenn dieses Objekt seine Arbeit getan hat, dann soll es bei den beiden folgenden Objekten jene Standardmethode aufrufen'.

Alle Objekte sind dann von irgendeiner Klasse abgeleitet, die so eine Standardmethode hat oder implementieren eine passende Schnittstelle.

Hm. Also ich seh hier ein MEssageQueue.Message.Body As Object und einen BodyStream. Ich vermute schon, dass die messagequeue serialisierte objekte enthalten kann. Es ist allerdings die grosse frage, ob es nicht mit kanonen auf spatzen geschossen ist, diese Message Queue für multithreading zwecke zu gebrauchen/mussbrauchen.

Withevents ist schon nett.  Wenn ich jetzt noch irgendwie den Threading-Kontext zur Withevents-variable definieren könnte und mir das msg-gequeue sparen könnte wäre das schon schön. Genauso sollte das bei funktionsaufrufen möglich sein. (Träum)

Das ActiveObject Pattern kenn ich; Musst aber aufpassen, sind 2, 3 Denkfehler in der wurstl-ausführung drin. (Kann dir leider nicht mehr sagen, was das war)

Was mir zu dem Pattern aufgefallen ist:

- Funktionsaufrufe und Ereignisszuteilung kannst du über diesselbe MsgBase.WaitUntilConsumed methode abarbeiten, die virtuell ist, weil...:

- ...Interessant - wo ich gerade dranhänge - ist auch, dass es Composite-Ereignisse gibt: Die haben folge-ereignisse, die aber erst während der abarbeitung des ereignisses instanziert werden. Eine wartevorgang muss (optional?allgemein definierbar?)diese folgeereignisse mit einschliessen (können). Eine direkte Verknüpfung mit einem ProgressWindow ist denkbar.

- In grösseren Projekten grösser sagmal 20 ActiveObject-Klassen lohnt es sich mit codegeneriung zu arbeiten, um das verpacken/entpacken der parameter in die entsprechende message objekt zu realisieren: (Das senkt Fehlerquellen und macht den user-code kompakter.) 

- pro funktionsaufruf gibt es eine generierte klasse mit hartkodierten membern für jeden parameter. (dürfte auch unter .net performance bringen)

- Für Codegenerierung gibts den namespace System.CodeDOM.

- Für die Client-Seite brauchst du eine code generierung. (oder du musst die msg.-objekte manuell befüllen, was seeehr ätzend ist)

- Ich glaube für die Server seite brauchst du nicht unbedingt eine code genierung sondern kannst du auch die dot net reflection verwenden: irgendwie so:

servant.GetType.GetMember(aMsg.MemberName, aMsg.ParameterTypeArray).Invoke(obj, aMsg.PArameterArray)

(ok, das MemberInfo Objekt speicherst du dir sinnigerweise in der msg ab, statt dem MemberNAme)

ein bisschen mehr dynamische sprache und aspektorientierte programmierung wären hier sehr hilfreich... vielleicht ein MemberInfo.BeforeInvoke ereigniss... oder ein GetType.Members.Add vielleicht (Träum)

gruss,

karle

PS:

ParalellExecutionContext.AddDecorator hmm...

generier dir doch ein paar zeilen code für die threadmain daraus:

In Dot net kannst du recht einfach zur laufzeit assemblies generieren und ausführen. Fügst du noch eine REferenz auf deine eigene Assembly an und du kannst den applikationskontext im aufruf übergben: CodeDomSample:

http://msdn.microsoft.com/en-us/library/h82xde1t.aspx

was du da machst gefällt mir ich glaub ich muss mich mal für deinen job bewerben ;)

ach ja, und wenn du schon multithreading technisch unterwegs bist - hast du dir asml schon angeschaut?

http://research.microsoft.com/fse/asml/

steckt allerdings noch in den kinderschuhen (word als codeditor verausgesetzt; der compiler nimmt word dokumente als eingabe - wenn ich das richtig verstanden habe =)

Vielen Dank für die tollen Ideen.
Es gibt für mich also noch einiges dafür zu erforschen, aber es sieht vielversprechend aus.
Schön finde ich auch daß meine Idee Anklang findet.

karle:

was du da machst gefällt mir ich glaub ich muss mich mal für deinen job bewerben ;)

Solche Sachen mache ich als Hobby, damit ich nicht einroste.