boost threads
-
wie benutzt man boost threads?
beispiel an dieser funktion:
void hund(){
cout << "loko";
}
-
So z.B.:
#include <iostream> #include <boost/thread.hpp> void hund() { while ( true ) { std::cout << "loko" << std::endl; } } int main() { boost::thread thrd1( &hund ); boost::thread thrd2( &hund ); std::cin.get(); }Oder Synchronisiert:
#include <iostream> #include <boost/thread.hpp> boost::mutex m; void hund() { while ( true ) { boost::mutex::scoped_lock lock( m ); std::cout << "loko" << std::endl; } } int main() { boost::thread thrd1( &hund ); boost::thread thrd2( &hund ); std::cin.get(); }Oder mit Argumenten (über gebundene Parameter):
#include <iostream> #include <boost/thread.hpp> #include <boost/bind.hpp> boost::mutex m; void hund( int id ) { while ( true ) { boost::mutex::scoped_lock lock( m ); std::cout << "Thread #" << id << ": loko" << std::endl; } } int main() { boost::thread thrd1( boost::bind( &hund, 1 ) ); boost::thread thrd2( boost::bind( &hund, 2 ) ); std::cin.get(); }
-
danke. wie kann ich einen thread beenden?
-
Es gibt eine ausführliche Hilfe zu boost::threads. Diese zu lesen ist wohl nicht zu viel verlangt oder?
Zu finden ist sie hier: http://www.boost.org/doc/html/threads.html
-
Ich hab gerade diesen eigentlich überflüssigen Thread gesehen,
aber jetzt stellt sich mir zu diesem Code trotzdem eine Frage,
da ich mit boost noch keine Erfahrung machen konnte:boost::thread thrd1( boost::bind( &hund, 1 ) );Wenn der Scope danach verlassen wird, birgt das irgendwelche Gefahren?
Denn das Objekt ist ja nur auf dem Stack erzeugt worden.Gruß,
Booster
-
Der Hund ist ein Funktionszeiger und wird intern von Objekt gehalten das von boost::bind erzeugt wird.
grüße
-
ok eine letzte frage:
void SocketThread()
{
while(1)
{
}
}
// <--- auf das ende wartest du ewig.Du musst eine variable (bool) für des Ende erstellen.
Auf diese Variable nur über boost::mutex zugreifen.
Anschließend kannste die zum beenden gleich true setzen um die While schleife zu beenden.wie kann ich das mit dem mutex verwirklichen?
-
loko schrieb:
ok eine letzte frage:
void SocketThread()
{
while(1)
{
}
}
// <--- auf das ende wartest du ewig.Du musst eine variable (bool) für des Ende erstellen.
Auf diese Variable nur über boost::mutex zugreifen.
Anschließend kannste die zum beenden gleich true setzen um die While schleife zu beenden.wie kann ich das mit dem mutex verwirklichen?
Hat der/diejenige überhaupt verstanden was ein Mutex ist/macht? Warum schaust du dir nicht einfach das Manual an. Bzw den entsprechenden Code
grüße
-
das sagt mir eher wenig
könntest du nicht mal bitte ein beispiel machen?dein "der Synchronisiert:" code hat die gleichen auswirkungen wie der erste code
-
loko schrieb:
dein "der Synchronisiert:" code hat die gleichen auswirkungen wie der erste code
Durchaus nicht. Vllt wirds deutlicher wenn du mal einen längern Text ausgibst.
-
jetzt seh ichs auch
kannst du mir noch ein beispiel geben wie ich aus einem endlosschleife in einem thread kommen kann oder wie ich während dem programmablauf die variable ändern kann die die schleife laufen lässt
while(a)
-
bRun = true; while ( bRun ) { if ( xyz ) bRun = false; }Sind doch totale Basics und hat garnichts mit dem Thema zu tun egtl... Zeig doch einfach ein wenig Eigeninitiative.
-
Hi,
kann es sein, dass loko meint: "Wie kann ich den Thread von außen beenden ?"
... so eine Art "kill" ?
Gruß,
Simon2.
-
Auch einfach:
Thread 1:
bRun = true; while (bRun) { // ... }Thread 2:
bRun = false;:p
-
LordJaxom schrieb:
Auch einfach:
Thread 1:
bRun = true; while (bRun) { // ... }Thread 2:
bRun = false;:p
Ich weiß ... aber vielleicht loko nicht.
BTW: Sollte nicht der Zugriff auf bRun serialisiert werden (hast Du vllt. daran gedacht, aber ich weiß nicht, ob loko das klar ist) ?
Gruß,
Simon2.
-
Hm, universell gesehen vielleicht. Aber ist nicht (zumindest auf den allermeisten Plattformen) der Zugriff auf einzelne integrale Daten sowieso atomar?
Also ich bin bisher bei einfachen Worker-Threads immer gut gefahren mit einer while (active) {...} Schleife. Wäre das auf Intel-Linux-Plattformen potentiell gefährlich, müsste ich jetzt jede Menge Programme ändern

-
Hi,
also im Vorliegenden Fall hast Du's natürlich noch ein wenig einfacher, weil nur ein Thread schreibt, aber ich hätte da Bedenken. Wir haben (unter AIX) auch solche Zugriffe serialisiert .... letztlich ist aber auch die Frage, was Du mit den Daten machst: Hier greifst Du ja wirklich nur für eine einzige Information zu - wir haben oft Fälle, wo noch mehr mit der Variablen "gearbeitet" wird ("long(er) unit of work") - da reicht es natürlich nicht, wenn jeder einzelne Zugriff serialisiert wird...
Ach ja: Wenn bRun nicht volatile deklariert ist .... könnte dann ein übereifriger Compiler nicht den Lesezugriff (spätestens ab dem Zweiten) wegoptimieren ?
Gruß,
Simon2.
-
Simon2 schrieb:
Ach ja: Wenn bRun nicht volatile deklariert ist .... könnte dann ein übereifriger Compiler nicht den Lesezugriff (spätestens ab dem Zweiten) wegoptimieren ?
Ja, hatte sowas mal versehentlich nicht volatile gemacht, wodurch meine Anwendung nach einem join in dem Thread hängen geblieben ist.
Greetz
-
LordJaxom schrieb:
Hm, universell gesehen vielleicht. Aber ist nicht (zumindest auf den allermeisten Plattformen) der Zugriff auf einzelne integrale Daten sowieso atomar?
Also ich bin bisher bei einfachen Worker-Threads immer gut gefahren mit einer while (active) {...} Schleife. Wäre das auf Intel-Linux-Plattformen potentiell gefährlich, müsste ich jetzt jede Menge Programme ändern

Ohne volatile ist es gefährlich. Und aufm x86 kannst du soweit ich weiss auch nur davon ausgehen dass ein dword aligned Lese ODER Schreib-Zugriff (aber auf keinen fall read-modify-write!) auf ein dword "atomic" ist. Ein "bool" wäre also "böse", sobald du das "bool" durch "DWORD" ersetzt sollte es OK sein.
Ob die MESI Implementierung auf nem Pentium es schafft 2 "gleichzeitige" Schreibzugriffe auf benachbarte Bytes (innerhalb eines dwords, z.B. Adressen 0x1000 und 0x1001) so hinzubiegen dass keiner der beiden geschriebenen Werte verloren gehen kann ... weiss ich nicht. Falls es jmd. weiss möge er es mich bitte wissen lassen.
-
Hi
Auch mal grad ne Frage zu dem Beispiel.
Kannman die beiden Threads auf zwei Konsolen ausgeben lassen, also jede auf einer eigenen?
Oder geht das nicht mit Standardmitteln, wenn nicht, dann für Linux.
Grüsse und Danke im voraus
-
Simon2 schrieb:
BTW: Sollte nicht der Zugriff auf bRun serialisiert werden (hast Du vllt. daran gedacht, aber ich weiß nicht, ob loko das klar ist) ?
Welchen Sinn soll das geben, und von was redest du denn????