tutorial zu programmierung mit threads

Steve03

hi,
sry wenn das schonmal gefragt wurde, ich hab kurz gesucht aber nix gefunden
kennt ihr ein gutes tutorial, wie man unter win mit threads programmier?
thx!

grüsse steve

c.rackwitz

mich würd des auch interessieren.
vielleicht auch thread libraries generell (also gute portierungsmöglichkeit).

flenders

Wozu genau soll das Tutorial denn sein?! Denn im Prinzip ist ja ein Thread einfach nur eine Funktion, die eben als neuer Thread ausgeführt wird und dann quasi parallel abläuft - sprich: du musst eben bei Ressourcen, auf die von mehreren Thread zugegriffen werden soll, darauf achten, dass nicht mehrere Threads an den gleichen Daten "gleichzeitig" rumpfuschen

c.rackwitz

wie es mit dem fragesteller aussieht k.A.
ich bräuchte lediglich ein paar quellen, wo ich mich in die benutzung von win threads einlesen kann. wenn es noch ne threadlib gibt, die auf vielen linux varianten verwendbar ist (gentoo ist pflicht, suse würd ich ganz gerne mit abdecken), würd mich das auch interessieren.

thx

hi!
probiers mit boost::threads
Boost is an organization started by members of the C++ Standards Committee Library Working Group to develop new source libraries for C++

http://www.boost.org/libs/thread/doc/

tutorial:
http://www.cuj.com/documents/s=8470/cuj0205kempf/

sample:

#include <boost/thread/thread.hpp> 
#include <iostream> 

void MessageSend() 
{ 
        std::string message; 

    while(1) 
    { 
                message = ""; 

        do{ 
            std::getline(std::cin, message); 
        }while(message.empty()); 

        std::cout << "Thread MessageSend started! Message: " << message << std::endl; 
    } 
} 

void MessageReceive() 
{ 
    while(1) 
    { 
        std::cout << "Thread MessageReceive started" << std::endl; 
    } 
} 

int main() 
{ 

    boost::thread thrd1(&MessageSend); 
    boost::thread thrd2(&MessageReceive); 
    thrd1.join(); 
    thrd2.join(); 

        std::cin.get(); 
        return 0; 
}

cu..ich hoff das reicht dir!

Da Threads OS abhängig sind, könnte es mit einer Lib für beide Systeme (Windows, Linux) schlecht aussehen.

c.rackwitz

danke surf, da bleib ich mal dran

hi luckie! bist du der luckie aus der DP?

native threads für win reichen mir anfangs schon. wenn ich dann mit ifdef arbeiten muss und doppelt code schreiben darf, auch nicht so schlimm.

thx

Luckie schrieb:

Da Threads OS abhängig sind, könnte es mit einer Lib für beide Systeme (Windows, Linux) schlecht aussehen.

genau dann nimmt man ja boost! boost thread sind system unabhängig!

cu

Spacelord

Naja,letztendlich hast du damit aber doch keinerlei Einfluss auf das Scheduling von Windows.Dein "Prozess"(eigentlich der primäre OS-Thread!) bekommt seine Zeitscheibe zugeteilt und wenn er die intern auf 50 "Threads" aufteilt interessiert das Windows nicht die Bohne.Ob sich damit grossartige Performancegewinne erzielen lassen?

MfG Spacelord

SirLant

Spacelord schrieb:

Naja,letztendlich hast du damit aber doch keinerlei Einfluss auf das Scheduling von Windows.Dein "Prozess"(eigentlich der primäre OS-Thread!) bekommt seine Zeitscheibe zugeteilt und wenn er die intern auf 50 "Threads" aufteilt interessiert das Windows nicht die Bohne.Ob sich damit grossartige Performancegewinne erzielen lassen?

MfG Spacelord

Wenn ich dich jetzt richtig verstanden habe, dann hast du den Sinn der Threads falsch verstanden.
Nen Thread verwendet man um Arbeiten parallel auszuführen (z.B. ne Berechnung im Hintergrund und ne GUI im Vordergrund), die sich sonst gegenseitig blockieren würden.

Wenn man nen weiteren Prozess braucht, muss man natürlich nen Prozess starten und keinen Thread (nen Prozess enthält ein oder mehrere Threads).

Christoph

Spacelord schrieb:

Naja,letztendlich hast du damit aber doch keinerlei Einfluss auf das Scheduling von Windows.Dein "Prozess"(eigentlich der primäre OS-Thread!) bekommt seine Zeitscheibe zugeteilt und wenn er die intern auf 50 "Threads" aufteilt interessiert das Windows nicht die Bohne.

IIRC würde das nur dann zutreffen, wenn Windows-Programme ihre Threads selbst simulieren müssten, und zwar ohne Kernelunterstützung.
Da Windows aber Threads anbietet, weiß es natürlich davon. Windows gibt den einzelnen Threads Rechenzeit, nicht dem Prozess.

Spacelord

Da hab ich mich wohl unglücklich ausgedrückt.
Wenn ich boost Threads benutze hat dass doch keinerlei Einfluss auf Windows!
Wenn ich mit WinApi-Funktionen in einem Prozess mehrere Threads erstelle bekommt jeder dieser Threads vom OS früher oder später Rechenzeit zugeteilt.Wenn ich aber im primären OS Thread,diese boost Pseudo Threads benutze bekommt dennoch nur der primäre OS Thread Rechenzeit und die Pseudothreads müssen diese unter sich aufteilen.

MfG Spacelord

SirLant

Das sind keine Pseudothreads, das ist nur ne Wrapper-Klasse um die Threads der einzelnen Systeme.

Spacelord

Ach so,
dann ist das was anderes.Ich war davon ausgegangen dass die boost Threads keine "echten" Kernel Threads erstellen.

MfG Spacelord

c.rackwitz

gut zu wissen...

hab noch das hier gefunden, scheint ganz brauchbar:
http://www.linuxjournal.com/article.php?sid=3184

c.rackwitz

da boost.threads leider noch nicht so einen großen funktionsumfang hat (wie auf den seiten auch zugegeben wird), poste ich mal die relevanten links für winapi threads:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/multiple_threads.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/creating_threads.asp

John Doe

Wen du etwas ausführliches suchst kann ich dir nachfolgendes Buch empfehlen:
http://www.amazon.de/exec/obidos/ASIN/0201442345/qid=1097939260/br=3-1/br_lfncs__1/028-1363784-9752568
Ist zwar etwas älter stimmt inhaltlich aber immer noch, da sich die Konzept
seit NT nicht wesentlich geändert haben.

Hi c.rackwitz,
den Link auf "creating threads" finde ich zweischneidig weil in den meisten
Fällen, wenn dein Programm nämlich das C-Laufzeitsystem benötigt, die Verwendung
von CreateThread() zu Fehlern führt.

mfg JJ

c.rackwitz

was meinst du mit "C-Laufzeitsystem" und welche fehler können da auftreten?

RED-BARON

hallo,

ganz einfach. Wenn Du in Deiner Threadfunktion z.B. strlen() verwendest, darfst Du nicht mit CreateThread arbeiten, sondern MUST _beginthread[ex] verwenden. Wenn Du hingegen in Deinem Thread nur ein WINAPI-Funktionen verwendest reicht CreateThread aus.

Wie das jetzt im einzelen zusammenhängt, wage ich nicht zu nennen, aber z.B.
kannst Du

row = strtok(pString, '\r\n');
while(row) {
...
row=strtok(NULL, '\r\n');
}

verwenden. strtok ist aber nicht Threadsave, pString muß in der C-Runtime global gespeichert, sonst würde der Aufruf in der Schleife nicht funktionieren mit NULL.

und diese globale variable in der pString gespeichert ist ist nicht durch eine CriticalSection geschützt.

Wenn Du obige schleife in 2 Threads einsetzt, ist das Ergebniss der Schleifen
nicht definiert so zu sagen.

Außerdem muß auch die MultiThread-Version der C-Runtime gelinkt werden, und diese Stellt ebend _beginthread[ex] zur Vefügung.

strtok_r ist wohl die Mutithread-Version von strtok.

Evtl. ruft ja _beginthread[ex] später auch CreatThread auf, aber erstmal kann die C-Runtime "initalisiert" werden.

MfG
RB

John Doe

RED-BARON hat das "bekannteste" Beispiel angeführt, strtok() wird im allgemeinen
mehrfach hintereinander aufgerufen und da die Funktion nicht threadsafe ist geht
der "Merker" verloren. Auch die Variable errno, in der Fehler abgespeichert
werden, funktioniert nicht und einiges andere wohl auch nicht mehr.
In dem angegebenen Buch oder auch bei Jeffrey Richter wird genaueres erklärt.

mfg JJ

c.rackwitz

was du mit c-runtime konkret meinst, hab ich immer noch nicht gelesen.
mit den ganzen mutexes und critical sections und was es noch gibt, will ich nicht einsteigen.
kennst du ein tutorial, mit dem ich in die win32 threading programmierung einsteigen kann? also z.b. 2 gleiche threads starten, die 1000 mal "." oder "|" in die konsole schreiben. sowas ist anschaulich und erschlägt einen nicht gleich.

ich compiliere übrigens mit g++, nicht mit vc++ oder builder.