[UDF+Example] _InfiniteCore - MultiThreading- Mehrere Funktionen gleichzeitig verarbeiten

    Hi!

    Hier mal meine UDF für softwareseitiges Multithreading in AutoIt.
    Für die die nicht wissen was das ist, hier mal Alinas Erklärung:

    Multithreading
    Meist ist mit dem Begriff das softwareseitige Multithreading gemeint, bei dem in aller Regel nur ein Prozessor beteiligt ist. Die dann vorhandene scheinbare Gleichzeitigkeit wird in Wirklichkeit durch geschickte Programmierung erzeugt. Einzelne Threads eines Prozesses/Tasks können sehr schnell auf zeitkritische Ereignisse reagieren, während andere Threads langwierige Berechnungen durchführen.

    Das ganze Ding heißt InfiniteCore, und funktioniert folgerndermaßen:

    Man hat z.B. ein großen Skript. Darin wird etwas berechnet. Diese Berechnung ist aber groß und blockiert den Programmfluss. Das heißt es wäre besser würde sie simultan zum Mainskript ausgeführt werden.

    Also lagert man die Funktion in einen "Core" aus. Ist die Berechnung wichtig, kann man die Priorität des Cores gegenüber anderen verstellen.

    Alle Cores benutzen einen Value Pool zur Kommunikation mit dem Mainskript und untereinander. So können hochkarätige Cores verknüpft werden und Informationen ohne Zeitverlust austauschen. Egal zu welchen Zeitpunkt kann auch das Mainskript im Value Pool rumfingern, denn Values sind nicht Core spezifisch.

    Jeder Core lässt sich natürlich einzeln wieder beenden. So kann das Mainskript den ganzen ihm zugewiesnen Speicher nutzen + die Speicher der Cores.

    Alles das wird auch im Example verdeutlicht, welches natürlich nicht das gesamte Nuzungspektrum zeigt.

    Alles nötige im Anhang. Viel Spaß beim Corchen :P

    MfG, campweb

    ähm.. beim Example dreht meine Maus vollkommen durch..
    Ich kann mir im Moment noch keinen Code ansehen, also das gehört so oder?
    Ansonsten gute Idee..

    MFG Schnacko

    Zitat von campweb

    Hier mal meine UDF für softwareseitiges Multithreading in AutoIt.

    Naja nicht ganz.
    Was ich bisher davon gesehen habe ist dass du kein Multithreading sondern Multiprocessing geschaffen hast.
    Hierbei ist es aber so dass die einzeln gestarteten Prozesse eben nicht nur auf einen Prozessorkern beschränkt bleiben sondern vom Betriebssystem frei verteilt werden können.

    Das ganze ist clever und simpel nachvollziehbar mit wenigen Mitteln umgesetzt - ich finds klasse.
    Wenn man noch einen etwas performanteren Zwischenspeicher als ein Edit-Control nehmen würde und Mutex-artige Strukturen dazu nimmt um Race Conditions auf dem "Zwischenspeicher" zu vermeiden kann man da schon eine Menge Blödsinn mit anstellen :)

    Wie gesagt - sehr schöne Idee :thumbup:

    @Aspirin Danke fürs Feedback. Bei der Performance reicht für mich das Edit

    @Schnacko Ich habe extra das Example ausführlichst kommentiert. Dann lies dir das doch mal durch...

    MfG, campweb

    Noch irgendwelche Verbesserungsvorschläge oder Bug´s. Keine von den 30 Downloadern?

    MfG, campweb

    Zitat von campweb

    Noch irgendwelche Verbesserungsvorschläge oder Bug´s. Keine von den 30 Downloadern?


    Es funktioniert doch ganz gut. Bei deinem StringSplit hast du aber nie das Flag 1 angegeben, das für eine korrekte Funktion benötigt wird.
    Und hier sind einige Vorschäge: Ersetze deinen Var-Pool mit einem durch AutoItObject erzeugten Objekt, erstelle eine Event-API, sodass die Prozesse sioch gegenseitig Nachrichten schicken können ... ;)

    Zitat von progandy

    Und hier sind einige Vorschäge: Ersetze deinen Var-Pool mit einem durch AutoItObject erzeugten Objekt

    Wie meinst du das genau? Ich bin noch nicht so bewandert in Sachen Objekte.

    Zitat von progandy

    sodass die Prozesse sioch gegenseitig Nachrichten schicken können

    Das können Sie doch über die Variablen. Oder fällt das dann beim Objekt weg ?(

    MfG, campweb

    Zitat von campweb

    Wie meinst du das genau? Ich bin noch nicht so bewandert in Sachen Objekte

    Ich meinte das so: http://www.autoitscript.com/forum/topic/128627-access-autoit/

    Zitat

    Das können Sie doch über die Variablen. Oder fällt das dann beim Objekt weg ?(


    Ja, es geht über die Variablen oder das Objekt. Ich meinte aber ein richtiges Event so wie man z.B. Nachrichten an Fenster schicken kann, ohne dass das Fenster jetzt andauernd eine Variable prüfen muss.

    Ich vestehe leider nicht, was der unschied dazu sein soll: http://msdn.microsoft.com/en-us/library/…v=vs.85%29.aspx
    Damit erreiche ich soch genau daselbe.

    EDIT: Vllt. etwas falsch ausgedrückt.
    Mit deiner "UDF" starte ich einen neuen Process, und mit meiner geposteten API FUnktion wird ein Neuer Thread gestarten, indem man dann lanwierige Rechenarbeit erlediggen kann.

    Das finden von Rechtschreibfehlern muss sofort und unverzüglich dem Autor gemeldet werden. Das eigennützige Verwenden dieser Rechtschreibfehler ist strengstens untersagt und kann mit Freiheitsenzug bestraft werden.

    StringRegExpTo2DArray

    Einmal editiert, zuletzt von Darter (23. August 2011 um 16:52)

    AutoIt ist nicht Threadsicher. Du kannst keinen AutoIt-Code als Thread starten, nur ASM oder DLL-Funktionen.

    Zitat von PenGuin

    Funktionen mit MsgBox'es kann man ohne Probleme Multithreaden.
    InetGet sollte auch noch gehen
    (dadurch, dass deren Parameter Threads verwenden würde ich mal sagen)


    Ich weiß genau, wovon ich spreche. Der AutoIt-Interpreter ist nicht threadsicher. Egal, welche Funktion du verwenden willst. Natürlich ist es möglich, die API-Funktion MesageBoxIndirect als Thread zu starten, aber das ist keine AutoIt-Funktion. InetGet startet intern auch einen Thread, wenn man es im Hintergrund laufen lässt, aber da ist der AutoIt-Interpreter ebenfalls nicht einbezogen, das sind alles Threads in reinem nativem Code.
    Jegliche Funktion, die per DLLCallbackregister registriert und dann als Thread gestartet wird lässt AutoIt zu 90% abstürzen,oder AutoIt beendet sich sobald der Thread fertig ist. Das geschieht auch, wenn die Funktion leer ist. Ich habe das selbst schon ausführlichst getestet.

    Und jetzt Back to Topic.

    Edit: Ich möchte anmerken, dass ich mich nicht angegriffen fühlte, da habe ich mich bei der Wortwahl etwas vertan ;)

    Einmal editiert, zuletzt von progandy (23. August 2011 um 22:05)

    Zitat von progandy


    Ich weiß genau, wovon ich spreche. [...]

    Bitte nicht gleich angegriffen fühlen, wenn ich zu anderen Ergebnissen gekommen bin und diese deiner Aussage widersprechen :thumbdown:


    @Topic:
    Sicherlich praktisch für diejenigen die ihre Berechnungen nicht als Inline ASM programmieren können und ist sicherlich auch die leichtere (inperformantere) Wahl.
    Insofern ein netter Zusatz ! :)

    Hey... nette UDF aber es handelt sich hier nicht um Multithreading sondern um Multiprocessing :P
    Erinnert mich ein bisschen an die CoProc.au3, ist ähnlich aufgebaut halt mit envget/set... greetz