2 Aktionen gleichzeitig ausführen

hustbaer

Das Wort "Wechselwirkung" ist so vollkommen unpassend dass ich auch überzeugt davon war dass es sich um einen Troll handelt.

@xBlackKnightx: Entschuldigung an dieser Stelle für das Kommentar in einem anderen Thread, ich dachte du schreibst absichtlich Müll (in diesem Thread hier).

@Topic:
Wenn man die Sache ohne Multithreading lösen will, dann sollte man wohl state-machines verwenden.

class MachineA
{
public:
    void Update()
    {
        switch(m_state)
        {
            // ...
        }
    }
    // ...
private:
    // ...
};

class MachineB
{
public:
    void Update()
    {
        switch(m_state)
        {
            // ...
        }
    }
    // ...
private:
    // ...
};

int main(int, char**)
{
    MachineA a;
    MachineB b;

    while(!(a.IsDone() && b.IsDone())
    {
        a.Update();
        b.Update();
    }
}

Oder so ähnlich.
Je nach Plattform/Framework/... kann man sich auch fertiger Konstrukte bedienen, wie z.B. Windows (unter Windows, wxWidgets, ...), wo man dann Messages als Events verwendet, und sich z.B. Timer setzt (die dann ne Message schicken) wenn man etwas periodisch machen muss ohne dass ein externes Ereignis auftritt.

HumeSikkins

Wenn man die Sache ohne Multithreading lösen will, dann sollte man wohl state-machines verwenden.

Oder so eine alte, aber immer noch gute Idee, wie das Active-Object-Pattern.

Woooza

Autsch....
So viele verschiedene Antworten.....mhh....ich probier einfach mal n paar aus und schau welches sich für mein Problem am besten eignet....
Thx an alle!

hustbaer

@HumeSikkins:
Naja, weiss nicht ist ein Active Object keine state machine? Denke schon...
Egal.

HumeSikkins

Naja, weiss nicht ist ein Active Object keine state machine? Denke schon...

Hättest du Command geschrieben, würde ich zustimmen, aber eine state machine muss ein Active Object weder implementieren noch sein. In meinen Augen ist state machine sowieso ein tiefer liegenedes Konzept.

Egal.

Oh. Tut mir leid

hustbaer

HumeSikkins schrieb:

Naja, weiss nicht ist ein Active Object keine state machine? Denke schon...

Hättest du Command geschrieben, würde ich zustimmen, aber eine state machine muss ein Active Object weder implementieren noch sein. In meinen Augen ist state machine sowieso ein tiefer liegenedes Konzept.

Ein Active Object hat einen State (pending, complete, ...) und Events (z.B. completed) die für state transitions sorgen. Was ist daran bitte keine state machine? Verstehe nicht was du meinst.

Egal.

Oh. Tut mir leid

Blubb?

EDIT: dann mach mers halt wieder her wenn schon so ein Koffer geantwortet hat.

@HumeSikkins: wir sprechen hier schon über das selbe, also inetwa dashier: http://www.titu.jyu.fi/modpa/Patterns/pattern-ActiveObject.html

hustbaer schrieb:

HumeSikkins schrieb:

Naja, weiss nicht ist ein Active Object keine state machine? Denke schon...

Hättest du Command geschrieben, würde ich zustimmen, aber eine state machine muss ein Active Object weder implementieren noch sein. In meinen Augen ist state machine sowieso ein tiefer liegenedes Konzept.

Ein Active Object hat einen State (pending, complete, ...) und Events (z.B. completed) die für state transitions sorgen. Was ist daran bitte keine state machine? Verstehe nicht was du meinst.

Egal.

Oh. Tut mir leid

Blubb?

HumeSikkins

@hustbaer
Ich denke schon, dass wir vom selben Pattern reden, nur scheinst du eine konkrete Ausprägung zu meinen. Wenn ich ne Menge von Command-Objekten in eine Queue stopfe, diese kontinuierlich abarbeite und einige (oder alle) Command-Objekte sich nach der Ausführung wieder in die Queue hängen (oder auch alternative Commands), dann ist das ebenfalls eine Ausprägung des Active-Object-Patterns und weit und breit ist keine State-Machine zu sehen. D.h. natürlich überhaupt nicht, dass State-Machines ausgeschlossen sind. Die Bearbeitung der Queue könnte z.B. durch eine solche gesteuert sein. Nur ist das kein Zwang, der inheränt in dem Pattern steckt.

Und dein "Egal" signalisierte mir, dass du nicht daran interessiert warst andere Meinungen zu hören, sondern vielmehr deine rhethorische Frage als Fakt angesehen haben möchtest.

hustbaer

@HumeSikkins:
Das "Egal" sollte bloss bedeuten dass es mir nicht so wichtig ist , nicht dass ich überzeugt davon bin nun unbedingt Recht zu haben.

Ich sehe jetzt denke ich den Denkfehler den ich gemacht habe. Das Active Object Pattern lagert ja die Abarbeitung eines "Active Object" (ich glaube dass ist das was du "Command" nennst?) in einen anderen Thread aus. Daher ist hier keine explizite state machine notwendig.

Ich hatte zuerst den Eindruck dass alles in einem Thread läuft, da hier ja auch ursprünglich über Alternativen zu Multithreading gesprochen wurde, und nicht über spezielle Formen die aber auch zumindest 2 Threads brauchen.

Und sobald nurmehr 1 Thread für alles verwendet wird glaube ich muss das "Command" oder "Active Object" für alle nicht-trivialen Aufgaben eine state machine sein. Events für diese state machines können dann von verschiedensten Stellen z.B. über asynchronous io, timer, diverse os callbacks etc. kommen -- dann geht das auch ohne eigenen worker thread.

Mir kommt das Pattern halt ähnlich vor wie das IRP processing unter Windows NT -- und da gibts nicht notwendigerweise einen thread der IRPs arbeitet, und alle nicht trivialen IRPs sind im prinzip state machines. Meist recht einfache natürlich.

So. Weiss nicht, vielleicht hab ich das Pattern wirklich nicht verstanden, kannst mich ja korrigieren wenn ich wieder Dummsinn geschrieben hab

HumeSikkins

hustbaer schrieb:

Ich sehe jetzt denke ich den Denkfehler den ich gemacht habe. Das Active Object Pattern lagert ja die Abarbeitung eines "Active Object" (ich glaube dass ist das was du "Command" nennst?) in einen anderen Thread aus. Daher ist hier keine explizite state machine notwendig.

Die einfachste Variante des Active Object Patterns verwendet nur einen Thread. Genauergesagt eine (Endlos-)schleife, die kontinuierlich eine Queue von Command-Objekten (im Sinne des Command-Patterns) abarbeitet (das ist dann die Active Object Engine). Einzelne Command-Objekte führen (Teil-)Aktionen aus und hängen sich (oder andere Teil-Aktionen) dann wieder ans Ende der Queue. Damit kann man dann also letztlich ein MT-Thread ähnliches System bauen, dass nur einen BS-Thread verwendet. Die einzelnen Command-Objekte sind dabei die "Threads" (in Anführungszeichen, da es sich nicht um echte BS-Threads handelt), die man für gewöhnlich als run-to-completion tasks bezeichnet. Ein Grundsatz für einen solchen Task ist, dass er nicht blockierend sein darf. Ziel des Ganzen ist eine "temporale Entkopplung" von Aufgaben.

Natürlich gibt es Aufgaben, wo die Active Object Engine oder einzelne Active Objects sinnvollerweise durch eine State-Machine implementiert wird. Aber wie gesagt: das muss nicht sein.

Checker*amp*Murckser

igittigittigitt goto
In Assembler kannst du mit Sprungmarken zu arbeiten, aber doch nicht in C++, das ist extrem hässlicher Code, nimm Threads, hier gibts beispielcode für Threads unter Windows http://de.wikipedia.org/wiki/Thread_(Informatik)

hustbaer

Die einzelnen Command-Objekte sind dabei die "Threads" (in Anführungszeichen, da es sich nicht um echte BS-Threads handelt), die man für gewöhnlich als run-to-completion tasks bezeichnet. Ein Grundsatz für einen solchen Task ist, dass er nicht blockierend sein darf. Ziel des Ganzen ist eine "temporale Entkopplung" von Aufgaben.

@HumeSikkins: Ok, gut. Bloss ich nenne diese Art von Command-Objekt eben state machine Denn du kannst ja kaum irgendwas da drinnen machen was nicht trivial ist (also wo man nicht jedes mal das gleiche macht bei jedem Durchlauf). Ok, zugegeben, diese Command Objekte müssen den State nicht selbst halten sondern können auf irgendwelche anderen Objekte/Strukturen verweisen wo der drinnen ist. Trotzdem, in meinem kranken Hirn sind das dann state machines mit einem "tick" oder "update" Event der den ganzen Ablauf vorantreibt.

Bloss dass sie halt ein gemeinsames Interface haben, und in einer Liste/Queue stecken.

Oder anders argumentiert: was ist denn ein "Thread" (egal ob echt oder "nachgestrickt") wenn kein "Zustandsautomat" (aka. state machine)?

Schon... oder?