Hallo, ich würde mich gerne in die Thematik des Multithreadings einarbeiten. Nur stehe ich gerade vor dem Problem, dass ich gar nicht weiß wie ich anfangen soll. Ich habe z.B. das Buch "C von A bis Z" zu Hause. Dort wird das Thema unter dem Kapitel "Paralleles Rechnen" sehr kurz angeschnitt. Am Anfang steht, dass das Buch die POSIX-Threads-Biblothek behandelt und somit auch unter Windows verwendbar ist. Für nähere Informationen verweißt dieses Buch auf das Buch "Linux-UNIX-Programmierung" Kapitel 10. Dort wird die pthread-Library verwendet. Am Anfang steht jedoch. ............... Die Beispiele im Buch verwenden Linux-Threads und sind somit nicht ohne weiteres auf anderen UNIXen lauffähig. Die BSD-Threads z. B. arbeiten zum Teil ähnlich. Es kann aber sein, dass das eine Programm läuft und ein anderes nicht und daher auf die Linux-Threads verlinkt werden muss. Voraussetzung sind also Linux-Threads. ............. Im Internet habe ich nun recherchiert, dass es die POSIX Threads auch unter win32 verwendet werden können. Scheinbar gibt es jedoch auch eine extra Library für Windows. Kann mir jemand erklären, welche Bibliothek ich am sinnvollsten verwenden kann, welche Vorteile das hat und wo ich mich einlesen kann.
Um innerhalb deines Programms neue Threads anzuschubsen, brauchst Du keine Bibliotheken, dafür gibt es normale API-Funktionen, z.B. http://msdn.microsoft.com/en-us/library/ms682453%28v=vs.85%29.aspx Für Win wird dann wohl auch das MSDN die günstigste Quelle an Informationen sein. Hoffe damit ein Wenig geholfen zu haben, mfG ingo
Kommt drauf an was Du machen willst. Willst Du nicht nur auf einem Rechner sondern auch auf vielen Aufgaben verteilen können könnte MPI interesant sein, am einfachsten ist meiner Meinung nach openMP, da kann man z.B. eine Schleife einfach als parallel deklarieren, der compiler msacht den Rest. http://en.wikipedia.org/wiki/OpenMP Lies auch diesen Artikel: http://en.wikipedia.org/wiki/Parallel_programming_model
A. R. schrieb: > ich würde mich gerne in die Thematik des Multithreadings einarbeiten. > Nur stehe ich gerade vor dem Problem, dass ich gar nicht weiß wie ich > anfangen soll. Nun, der erste Schritt ist die Analyse. Stelle fest, ob du überhaupt Multithreading benötigst; erfahrungsgemäß kommt man dabei in der Mehrzahl der Fälle zum Resultat nein. Klingt jetzt blöde, aber Multithreading ist tatsächlich oft der falsche Weg. Du merkst das bei der Umsetzung spätestens daran, dass du mehr Zeit damit verbringst, Threads um Ressourcen gegenseitig auszusperren (Mutexen, Semaphore und so weiter), als Algorithmen zu programmieren... > Ich habe z.B. das Buch "C von A bis Z" zu Hause. Tu das weg, das taugt wenig. > Dort wird das Thema > unter dem Kapitel "Paralleles Rechnen" sehr kurz angeschnitt. Am Anfang > steht, dass das Buch die POSIX-Threads-Biblothek behandelt und somit > auch unter Windows verwendbar ist. Ja, die ist -- wie der Name schon sagt -- portabel. Die meisten Betriebssysteme halten sich neuerlich an POSIX. Multithreading in dieser Form ist unter UNIX aber eigentlich untypisch, in der Regel erledigt man das durch Multiprocessing in Form von Forks. Aber POSIX hat sich dann auch etabliert, außer unter Windows, natürlich. Windows bietet eine ganze Reihe von Routinen zum Multithreading an, mal mehr, mal weniger chaotisch. Die MSDN gibt dir da sicherlich Auskunft, viel Spaß beim wilden Casting :-)
Sven P. schrieb: > Die MSDN gibt dir da sicherlich Auskunft, > viel Spaß beim wilden Casting :-) zeigt mir doch mal bitte eine funktion die mit Threading zu tun hat, wo man casten muss?
Ingo Wendler schrieb: > Um innerhalb deines Programms neue Threads anzuschubsen, brauchst Du > keine Bibliotheken, dafür gibt es normale API-Funktionen, z.B. > http://msdn.microsoft.com/en-us/library/ms682453%28v=vs.85%29.aspx > Für Win wird dann wohl auch das MSDN die günstigste Quelle an > Informationen sein. > Hoffe damit ein Wenig geholfen zu haben, > mfG ingo Danke, hast schonmal geholfen. Finde msdn relativ unübersichtlich. Der Link war also schonmal eine große Hilfe. Konnte auch ein kleines Tutorian finden http://www.spieleprogrammierer.de/index.php?page=Thread&threadID=6661 . @Hans Mayer, das werde ich mir dem nächst durchlesen. Ersteinmal reicht jedoch mehrere Threads auf einem Rechner zu haben. Klingt aber sehr interessant. @Sven P., es geht um das Vorhaben aus diesem Link Beitrag "Screen Scraping C/C++" Ich rufe eine Funktion der curl-Bibliothek auf die eine nicht bekannte Anzahl Daten von einem Server empfängt (Verbindung A). Deswegen ist diese Funktion für eine unbekannte Zeit aktiv (Programm ist blockiert). Ich muss aber gleichzeitige weitere Verbindungen mit dem Server aufbauen um diesem mitzuteilen, welche Daten er über Verbindung A senden soll. Deswegen würde ich mich gerne mit Threadanwendung beschäftigen. >> Ich habe z.B. das Buch "C von A bis Z" zu Hause. >Tu das weg, das taugt wenig. Das Buch hat mir bis jetzt schon ganz gut geholfen. Aber selbstverständlich bin ich für weitere Literaturvorschläge offen. >Die MSDN gibt dir da sicherlich Auskunft, viel Spaß beim wilden Casting :-) Danke
Peter II schrieb: > Sven P. schrieb: >> Die MSDN gibt dir da sicherlich Auskunft, >> viel Spaß beim wilden Casting :-) > > zeigt mir doch mal bitte eine funktion die mit Threading zu tun hat, wo > man casten muss? Beim MPI, PostThreadMessage, Blanko-Parameter lParam und wParam.
> Aber selbstverständlich bin ich für weitere Literaturvorschläge offen.
Vieleicht nicht Literatur aber doch ein gut gemeinter Rat: Geh weg von
C, z.B. nach C++ (mit Boost) oder Java (bringt alles mit). In beiden
Fällen ist Mulithreading ∗wesentlich∗ einfacher als die native
Win-Thread-Schnittstelle.
HTH
A. R. schrieb: > @Sven P., > > es geht um das Vorhaben aus diesem Link > Beitrag "Screen Scraping C/C++" > [...] Ebendas wäre eigentlich ein typisches Beispiel gegen Threads. Aber leider ist die libcurl da tatsächlich nicht so ganz flexibel. Du hast ja ohnehin Puffer im TCP-Stack, von daher würde man sowas eigentlich elegant mit select() lösen. Dein Kernproblem ist ja nicht, etwas tatsächlich zu parallelisieren. Dein Kernproblem ist, dass du keinen Zustandsautomaten konstruieren kannst, woran die libcurl nicht ganz unschuldig ist. Du hast ja effektiv nichts, was man sinnvoll auf mehrere Prozessoren verteilen könnte, weil es so rechenaufwändig ist. Du weißt nur einfach nicht genau, wie es dem zweiten Programmpfad ergeht. Und ich verspreche dir, du wirst früher oder später mit Mutexen herumkleckern, um den anderen Thread unter Kontrolle zu halten ;-)
Sven P. schrieb: > Beim MPI, PostThreadMessage, Blanko-Parameter lParam und wParam. warum musst du da casten? kannst doch auch WPARAM/LPARAM als Datentype für dein Zeiger arbeiten.
Peter II schrieb: > Sven P. schrieb: >> Beim MPI, PostThreadMessage, Blanko-Parameter lParam und wParam. > > warum musst du da casten? kannst doch auch WPARAM/LPARAM als Datentype > für dein Zeiger arbeiten. Bitte was? Wenn ich etwas anderes, als ein Word bzw. Long mitgeben möchte, muss ich halt casten, egal ob implizit oder nicht. Und das treibt man ja da wirklich bis zum Exzess.
>> Aber selbstverständlich bin ich für weitere Literaturvorschläge offen. >Vieleicht nicht Literatur aber doch ein gut gemeinter Rat: Geh weg von >C, z.B. nach C++ (mit Boost) oder Java (bringt alles mit). In beiden >Fällen ist Mulithreading ∗wesentlich∗ einfacher als die native >Win-Thread-Schnittstelle. >HTH Das wäre vielleicht sogar ganz hilfreich mich mit boost zu beschäftigen. Das scheint ja eine Sammlung von Bibliotheken etc. zu sein. Welche Vorteile hat die Verwendung von <boost/thread.hpp> gegenüber Windows.h? Kann mir vorstellen, das boost/thread.hpp langsamer als Windows.h ist.
A. R. schrieb: > Welche Vorteile hat die Verwendung von <boost/thread.hpp> gegenüber > Windows.h? damit bist du Platformunabhängig, könnte also auch unter linux laufen. > Kann mir vorstellen, das boost/thread.hpp langsamer als Windows.h ist. nein, der overhead ist minimal sie rufen auch nur die Windows funktionen auf. Aber ich bin selber kein Freund davon, die paar unterschiede zwischen Windows und linux bekomm ich selber recht gut in den Griff. Boost ist mir zu viel des guten.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.