Multithreading und GetMessage

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.

hustbaer

Th69 schrieb:

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

In dem Artikel geht es hauptsächlich darum dass der Autor nicht verstanden hat wie man CSingleLock verwendet, daraus dann falsche Schlüsse zieht und behauptet dass CMutex und CCriticalSection "broken" wären. Das einzige was broken ist ist allerdings sein verständnis von CSingleLock .

(OK, das ist nicht das einzige worum es in dem Artikel geht. Ein paar der anderen Punkte sind valide, aber für die meisten Anwendungen nicht von besonders grosser Bedeutung.)

Hallo zusammen,

vielen Dank für eure zahlreichen Beiträge.

Bei mir ist es momentan leider etwas stressig, sodass ich nicht vor nächstem Wochenende dazu kommen werde, etwas zu programmieren. Mit euren zahlreichen Links sollte ich es aber schaffen, ich werde sowohl thread als auch die mutexes aus der Win API nehmen. Das sollte am Sinnvollsten sein.

Wenn ihr also nicht noch weiter über den Autor des einen Links diskutieren wollt, könnt ihr das Thema schließen, ich steige bei der Diskussion leider aus.

Ganz lieben Dank noch einmal!

AnfängerX

EOP

Ich muss leider sagen, dass ich Mr. Newcomers Urteil weit mehr vertraue als hustbaers.

hustbaer

Es ist vollkommen egal wem du mehr vertraust. Das ist keine wischi-waschi Einschätzung wo es Meinungen geben kann. Das ist einfach so.
CSingleLock ist wie std::unique_lock dafür gedacht dass man es auf den Stack legt. Lokale Variable innerhalb einer Funktion. Bzw. ganz explizit nicht dafür gedacht concurrent verwendet zu werden.

Wer sich darüber aufregt dass es nicht thread-safe ist und/oder dass man damit nicht rekursiv locken kann, der hat das schlicht und ergreifend nicht verstanden.

Martin Richter

hustbaer schrieb:

Th69 schrieb:

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

In dem Artikel geht es hauptsächlich darum dass der Autor nicht verstanden hat wie man CSingleLock verwendet, daraus dann falsche Schlüsse zieht und behauptet dass CMutex und CCriticalSection "broken" wären. Das einzige was broken ist ist allerdings sein verständnis von CSingleLock .

(OK, das ist nicht das einzige worum es in dem Artikel geht. Ein paar der anderen Punkte sind valide, aber für die meisten Anwendungen nicht von besonders grosser Bedeutung.)

Genau...

EOP schrieb:

Mit einem "Central Controller" bin ich immer sehr gut gefahren.

ich habe mal etwas programmiert, bei dem sich die einzelnen threads bei einem "steuer-thread" in eine warteschleife eingetragen und dann aktiv mit sleep gewartet haben, bis sie an der reihe waren.

ist das sowas? bing spuckt da irgendwie nur müll aus.

EOP

Bei mir ging es eigentlich nur um HTTP-threads.
Die threads senden ihre Aufgabenanforderungen und Datenergebnisse per PostMessage an einen "Central Controller", der das verwaltet, Aufgaben zuteilt und neue Aufgabe versendet.
Funktioniert auch mit 256 threads hervorragend und echt flott.