Multithreading und GetMessage

Hallo zusammen,

nach langer Zeit C++ habe ich mich jetzt an WindowsProgrammierung gewagt und von MSDN das GetStarted Tutorial durchgearbeitet. Als nächstes möchte ich eine kleine 2D-Anwendung schreiben, bei der sich ein Ball (Kreis) in einem Fenster auf und ab bewegt. Sobald ich allerdings meine whileFunktion mit getMessage aufrufe steht natürlich mein Programm und der Ball still. Jetzt bin ich auf 3 Lösungsansätze gestoße:
1. Einen Timer, der nach der Zeit X, eine message schickt, die das Fenster neu malen lässt
2. PeekMessage anstelle von GetMessage
3 Multithreading

Mir persönlich gefällt Lösungansatz 3 am besten. 1 gefällt mir nicht, weil ich Unzuverlässigkeit bzw. Zeitverzögerungen bei vielen Messages befürchte. Bei 2 habe ich erstens das Gefühl, dass das nicht der von der MSDN empfohlene Weg ist, da MSDN selbst auf MultiThreading verweist. Zweitens finde ich es ungünstig, wie in 1 schon beschrieben, Messages und Paintbefehle hintereinander ausführen zu lassen.
Sind meine Gedanken soweit richtig oder übersehe ich etwas Wichtiges? Wie funktioniert das bei einem richtigen Spiel?

Zu 3 hätte ich außerdem die Frage, ob sich mein Vorhaben auch mit der <thread> Standardbibliothek umsetzen lässt oder ob ich über WindowsThread gehen muss.

Vielen lieben Dank für eure Hilfe, ohne euch bin ich aufgeschmissen!

AnfängerX

Multithreading ist gut.

Wenn du Multithreading nimmst, musst du natürlich immer die Zeit messen und abhängig davon den Kreis bewegen.

Biolunar

Definitiv PeekMessage. Threading ist schön und gut, verkompliziert aber alles und ist für einen Anfänger überhaupt nicht zu empfehlen.

Deine Hauptschleife wird in etwa so aussehen:

while (running)
{
    while (PeekMessage(&msg, 0, 0, 0, PM_REMOVE))
    {
        TranslateMessage(&msg);
        DispatchMessage(&msg);
    }

    simulate();
    render();
}

Siehe auch http://gameprogrammingpatterns.com/game-loop.html wie man mein Beispiel verbessern sollte.

rudi994

Hier ein Beispiel mittels Timer und dialogbox-basiertem Hauptfenster, Beitrag vom 11.10.2013 00:05, Anhang "animate_dialog.zip", in folg. Forum: https://www.mikrocontroller.net/topic/310726

Vielen Dank für die Links, ich schau Sie mir gleich an und würde mich am Wochenende noch einmal melden.

Danke noch einmal für die Links. Besonders im ersten Link bin ich auf extrem viele Dinge aufmerksam geworden, die ich nicht auf dem Schirm hatte.

Unabhängig davon würde ich es aber gerne mit Multithreading probieren. Kann ich hierfür die C-Bibliothek <thread> verwenden oder muss ich auf die Windows-Bibliotheken zurückgreifen? Wo ist denn der genaue Unterschied, was ist der Vorteil eines WindowsThreads gegenüber eines threads aus der C-Bibliothek? Wieso hat Windows hier eigene Funktionen?

Lieben Dank für eure Hilfe!

Martin Richter

AnfängerX schrieb:

Unabhängig davon würde ich es aber gerne mit Multithreading probieren.

Ich programmiere keine Spiele, aber grundsätzlich würde ich es vermeiden, gerade was UI betrifft. Da gibt es sehr spezielle Dinge, dass zum Beispiel Fenster an einen Thread gebunden sind...

Wenn ich Diene Fragen lese, würde ich Dir dringend erstmal zu einer single threaded Lösung raten...

Kann ich hierfür die C-Bibliothek <thread> verwenden oder muss ich auf die Windows-Bibliotheken zurückgreifen?

Geschmacksache... was meinst Du wie <thread> seine Threads auf dem OS Windows implementiert? Natrülich mit der Windows API.

Wo ist denn der genaue Unterschied, was ist der Vorteil eines WindowsThreads gegenüber eines threads aus der C-Bibliothek? Wieso hat Windows hier eigene Funktionen?

C/C++!=OS

Meinst Du die C Compiler bringen Ihr eigenes OS mit?

AnfängerX schrieb:

Wo ist denn der genaue Unterschied, was ist der Vorteil eines WindowsThreads gegenüber eines threads aus der C-Bibliothek?confused:

der vorteil der winapi allgemein ist, dass du alles ganz genau einstellen kannst bzw. maximale freiheit hast, während man bei bibliotheken immer versucht, das alles etwas einfacher zu machen, da diese ganzen freiheiten oft gar nicht gebraucht werden.
also unter der annahme dass ich dir hier jetzt nichts falsches erzähle: du kannst unter windows z.b. angeben, dass thread1 und thread2 auf dem 1. cpu-kern mit normaler priorität laufen sollen und thread3 auf dem 2. mit echtzeitpriorität, das brauchst du aber oft gar nicht.

AnfängerX schrieb:

Wieso hat Windows hier eigene Funktionen?

weil windows ja sonst direkten zugriff auf die threadverwaltung geben müsste und jeder darin herumpfuschen könnte.

hustbaer

AnfängerX schrieb:

Kann ich hierfür die C-Bibliothek <thread> verwenden oder muss ich auf die Windows-Bibliotheken zurückgreifen? Wo ist denn der genaue Unterschied, was ist der Vorteil eines WindowsThreads gegenüber eines threads aus der C-Bibliothek? Wieso hat Windows hier eigene Funktionen?

Windows hat für alles eigene Funktionen.
Was meinst du wie die Funktionen in <thread> implementiert sind? Sie rufen die Windows-Funktionen auf.

Hallo zusammen,

vielen Dank für eure Antworten!

Bzgl. den Antworten von hustbaer und Herr Richter: Stimmt es dann, dass wenn ich ein Programm mit der <thread> Bibliothek von C/C++ unter Linux (beispielsweise in Ubuntu) compiliere/ausführe, auch eine Ubuntu API oder etwas Ähnliches aufgerufen wird?

Bzgl. meiner Ursprungsfrage, würde sich mein Programmiervorhaben mit der vereinfachten <thread> Bibliothek umsetzen lassen oder woran würde/könnte es scheitern?

Zu Wade1234s Antwort: Gibt es noch weitere Vorteile der Windows API, außer Prioritäten? Vielleicht hättet ihr noch einen Link speziell zum Thema multithreading für mich. Denn offensichtlich ist das ein unglaublich komplexes Thema, nur kann ich die Schwierigkeit noch nicht erkennen. In reinem C/C++ habe ich mich schon mit diesem tutorial ( https://www.youtube.com/playlist?list=PL5jc9xFGsL8E12so1wlMS0r0hTQoJL74M ) beschäftigt. In diesem Link ( https://www.spieleprogrammierer.de/27-tutorials/6661-einstieg-in-multithreading-unter-windows/ ) konnte ich die Schwierigkeit von multithreading leider auch nicht nachvollziehen...

@Herr Richter, könnten Sie mir vielleicht noch die "Geschmacksache" näher erläutern? Also, was an der Einbindung von <thread> als negativ angesehen wird.

Ganz, ganz lieben Dank euch allen, mühsam ernährt sich das Eichhörnchen!

Martin Richter schrieb:

AnfängerX schrieb:

Wo ist denn der genaue Unterschied, was ist der Vorteil eines WindowsThreads gegenüber eines threads aus der C-Bibliothek? Wieso hat Windows hier eigene Funktionen?

C/C++!=OS

Meinst Du die C Compiler bringen Ihr eigenes OS mit?

Jetzt blamiere ich mich wahrscheinlich:
Ich dachte immer, dass das OS aus einer Hochsprache entspringt, wie z.B. C/C++, und das diese der Grundstein für ein OS ist ...

EOP

Bei ihm kannst du schön was lernen: Mr. Newcomer (Herr Richter kennt ihn sogar persönlich [Ne, ich hab das nicht vergessen, Martin ;)])
http://www.flounder.com/mvp_tips.htm#hreads and Processes series

Martin Richter

AnfängerX schrieb:

Ich dachte immer, dass das OS aus einer Hochsprache entspringt, wie z.B. C/C++, und das diese der Grundstein für ein OS ist ...

Nein! Es ist höchstens die Sprache in der es geschrieben wurde.

Ansonsten hat ein OS und eine Bibliothek einer Sprache (wie thread) soviel gemeinsam wie eine Autofabrik und ein Werkzeugkasten. (OK etwas übertrieben... :D)

Die Compiler Hersteller müssen sowas wie die C-Runtime immer auf ein OS anpassen... Dito solche std-Bibliotheken.

AnfängerX schrieb:

Gibt es noch weitere Vorteile der Windows API, außer Prioritäten?

naja du kannst eben "alles" konfigurieren, das muss aber nicht unbedingt ein vorteil sein.

Denn offensichtlich ist das ein unglaublich komplexes Thema, nur kann ich die Schwierigkeit noch nicht erkennen.

die probleme fangen auch erst an, wenn mehrere threads auf eine variable zugreifen. wenn also 1500€ auf dem bankkonto liegen und thread1 900€ abheben will und thread2 1000€, dann zahlt die bank möglicherweise zuviel aus und das muss verhindert werden.

Hallo zusammen,

vielen Dank für eure zahlreiche Hilfe und den neuen Link!

Ich werde mich noch einmal in Ruhe mit dem Link beschäftigen. Aber wenn - jetzt nur beim drüber lesen - mutex oder CriticalSection nicht ordnungsgemäß funktionieren, dann verstehe ich die Komplexität meines Vorhabens... Allerdings stellt sich dann auch mein Programmierweltbild auf den Kopf. Denn wenn beispielsweise die Bibliothek <mutex> nicht funktioniert, funktionieren denn dann eigentlich alle anderen Bibliotheken richtig? Ich lese doch etwas falsch?!
Naja und in logischer Konsequenz kann ich dann natürlich auch nicht die einfache <thread> Bibliothek nutzen, sondern benötige die Windows API. Und ich darf mir etwas einfallen lassen, wie ich die Sychronisierung regle und welche Elemente überhaupt vor Mehrfach-Zugriff geschützt werden müssen. Vielleicht könntet ihr mir das noch mit einem kurzen "ja" bestätigen?

Nochmal ganz lieben Dank! und ich habe mir da ja ein wunderschönes Projekt herausgesucht

Martin Richter

AnfängerX schrieb:

Aber wenn - jetzt nur beim drüber lesen - mutex oder CriticalSection nicht ordnungsgemäß funktionieren, dann verstehe ich die Komplexität meines Vorhabens... Allerdings stellt sich dann auch mein Programmierweltbild auf den Kopf. Denn wenn beispielsweise die Bibliothek <mutex> nicht funktioniert, funktionieren denn dann eigentlich alle anderen Bibliotheken richtig? Ich lese doch etwas falsch?!

Wer sagt, dass Mutex und CriticalSection NICHT gehen?
Woraus schließt DU das?

Th69

Wohl aus Avoid CMutex, CEvent, CSemaphore and CCrticalSection, also die MFC-Implementierungen!!!

Aber davon war ja in diesem Thema nie die Rede, denn die C++ Standard-Bibliotheken <thread> und <mutex> werden wohl korrekt umgesetzt worden sein.

von mutex und co rede ich gar nicht. du wirst schon merken, was ich meine, wenn da nachher fehler auftreten und du das ganze debuggen darfst.

AnfängerX schrieb:

und ich habe mir da ja ein wunderschönes Projekt herausgesucht

hast du ja auch. also mir macht sowas spaß!

so kompliziert sind mutexes in der winapi aber auch nicht, du kannst sie also problemlos verwenden: https://msdn.microsoft.com/en-us/library/windows/desktop/ms686927(v=vs.85).aspx

Martin Richter

Th69 schrieb:

Wohl aus Avoid CMutex, CEvent, CSemaphore and CCrticalSection, also die MFC-Implementierungen!!!

Aber davon war ja in diesem Thema nie die Rede, denn die C++ Standard-Bibliotheken <thread> und <mutex> werden wohl korrekt umgesetzt worden sein.

Ich gehe in vielen Dingen nicht mit Joseph konform. Wie auch hier...
Joseph ist/war (ich weiß es nicht) sehr speziell. Ich glaube am liebsten würde er es lieben wenn alle noch Assembler programmieren...

EOP

Martin Richter schrieb:

Ich gehe in vielen Dingen nicht mit Joseph konform. Wie auch hier...
Joseph ist/war (ich weiß es nicht) sehr speziell. Ich glaube am liebsten würde er es lieben wenn alle noch Assembler programmieren...

The Best Synchronization Is No Synchronization: Alternatives to semaphores, mutexes, and CRITICAL_SECTIONs

http://www.flounder.com/no_synchronization.htm

It is easier to reason about synchronization when you use protocols like Positive Handoff and Central Controller than if you try to reason about mutexes and semaphores. Because there is no explicit synchronization, there is no possibility of deadlock.

Da ist schon was dran. Mit einem "Central Controller" bin ich immer sehr gut gefahren.