Abarbeitungsreihenfolge von Events

Hallo,
meine Klasse bildet eine Instanz einer Klasse, die u.A. 2 Events anbietet. Beide Events passieren ungefährt zeitgleich.

Ich habe nun eine Abfrage in einem Eventhandler die ein bool flag setzt:

Eventhandler1:
.....
returnclass.x += A;
if(condition)bool=true;

Eventhandler2:
returnclass.y += B;
...

und eine funktion die auf die boolsche Variable wartet

returnclass func_x(...)
....
while(!bool);
return returnclass;

Meine Frage nun:
Wenn die Kondition in Eventhandler1 wahr wird, wird dann aufjeden Fall noch ein möglicher Eventhandler 2 abgearbeitet? Oder kann es sein, dass meine Funktion "returnt" und erst DANACH noch ein eventueller Eventhandler2 abgearbeitet wird und diese Daten damit dem Aufrufer der Funktion nicht zur Verfügung stehen?

Oder werden anstehende Events generell normalem Code einer Klasse vorgezogen (vom Scheduler)?

Sorry für die seltsame Ausdrucksweise, ich hoffe es gibt jemanden der mein Problem versteht.

Gruss und Danke!

Hallo wildcard,

Oder werden anstehende Events generell normalem Code einer Klasse vorgezogen (vom Scheduler)?

ein Event zu feuern bedeutet letztendlich nichts anderes als alle registrierten EventHander auszurufen ... im gleichen Thread und somit synchron und somit ganze ohne Scheduler.

while(!bool);  

Ganz schlecht! Solltest du unbedingt vermeiden!

Da ich aber leider nicht verstanden habe, was du eigentlich erreichen willst, kann ich nichts dazu schreiben, wie es besser geht. Nur so eben auf keinen Fall.

herbivore

Hallo herbivore,

Ganz schlecht! Solltest du unbedingt vermeiden!

Kurze Frage aus Interesse: warum nicht?

m0rius

Um eine "Kunstpause" einzulegen, verwende Thread.Sleep(milliseconds). Eine while schleife ohne Inhalt kann seinen Inhalt nicht ändern(ausgenommen, mehrere Threads, da aber Stichwort->Waithandle), somit können Endlosschleifen auftreten.

Eine Kunstpause mit while hat auch den Nachteil, das das Konstrukt 100% CPU-Last belegt. Thread.Sleep hingegen nicht.

@Herbivore,
ich denke seine Annahme war, dass Events in einem seperaten Thread ausgeführt werden und er mit while(!bool) auf das fertige Abarbeiten warten wollte.

Hallo kleines_eichhoernchen, hallo m0rius,

Eine Kunstpause mit while hat auch den Nachteil, das das Konstrukt 100% CPU-Last belegt. Thread.Sleep hingegen nicht.

ich würde noch deutlich weitergehen. Die CPU-Last ist nur einer der negativen ein Aspekt. Es geht noch weiter. Wenn man im GUI-Thread BusyWaiting macht, blockiert während der Wartezeit das GUI. Was sich dann noch weiter verschlimmert, wenn man auf einen anderen GUI-Event wartet, weil das dann nie kommt. Dann hat man sogar einen Deadlock. Mal wollte von while(!bool); ganz die Finger lassen. Thread.Sleep mildert nur die CPU-Last, aber verhindert nicht die anderen Nachteile.

Events sind ja außerdem dazu da, dass man eben nicht warten muss. Wenn man nicht weißt, welches Event später eintrifft und eine Aktion erst ausführen will, wenn der zweite Event eintrifft, dann muss man in beiden EventHandlern Code haben, mit dem man ermitteln kann, ob der Event der erste oder der zweite ist und wenn er der zweite ist, führt man die Aktion sofort aus. Ganz ohne while.

Und an anderen Stellen, an denen mal wirklich echt warten muss, kann man das über Semaphoren besser und professioneller machen.

ich denke seine Annahme war, dass Events in einem seperaten Thread ausgeführt werden und er mit while(!bool) auf das fertige Abarbeiten warten wollte.

Ja, das denke ich auch. Aber falsche Annahmen führen eben oft zu falschem Code. Und ich denke, dass der Code hier nicht nur ungünstig ist, sondern sogar echt falsch, weil es vermutlich zu einem Deadlock kommt.

herbivore