beispiel an dieser funktion:

void hund(){
cout << "loko";
}

#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();
}

Zu finden ist sie hier: http://www.boost.org/doc/html/threads.html

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

grüße

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?

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

dein "der Synchronisiert:" code hat die gleichen auswirkungen wie der erste code

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.

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)

Sind doch totale Basics und hat garnichts mit dem Thema zu tun egtl... Zeig doch einfach ein wenig Eigeninitiative.

kann es sein, dass loko meint: "Wie kann ich den Thread von außen beenden ?"

... so eine Art "kill" ?

Gruß,

Simon2.

Thread 1:

bRun = true;
while (bRun) {
    // ...
}

Thread 2:

bRun = false;

:p

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.

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

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.

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

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.

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

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????

Welchen Sinn soll das geben, und von was redest du denn????

Zugriffe serialisieren == dafür Sorge tragen dass Zugriffe in Serie ausgeführt werden

(mit anderen Worten: nicht gleichzeitig von verschiedenen Threads auf dasselbe Datum einschlagen)

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

Bevors auf der anderen Seite untergeht

Multiscreener schrieb:

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

Bevors auf der anderen Seite untergeht

Einfach /dev/ttyX als Datei oeffnen. (Das darf aber normal nur ein superuser)

LordJaxom schrieb:

Entenwickler schrieb:

Welchen Sinn soll das geben, und von was redest du denn????

Zugriffe serialisieren == dafür Sorge tragen dass Zugriffe in Serie ausgeführt werden

(mit anderen Worten: nicht gleichzeitig von verschiedenen Threads auf dasselbe Datum einschlagen)

Du sagst Sachen. Biste dir da denn sicher? Nicht dass ich mir nun was falsches merke!

Du sagst Sachen. Biste dir da denn sicher? Nicht dass ich mir nun was falsches merke!

Da sagste was. Geläufiger dürfte "synchronisieren" sein. Aber "serialisieren" habe ich in dem Zusammenhang definitiv auch schon gehört (nein, nicht von Simon :D)

Entenwickler schrieb:

Du sagst Sachen. Biste dir da denn sicher? Nicht dass ich mir nun was falsches merke!

Da sagste was. Geläufiger dürfte "synchronisieren" sein. Aber "serialisieren" habe ich in dem Zusammenhang definitiv auch schon gehört (nein, nicht von Simon :D)

Hab ich nicht gehoert, hat damit afaik nichts zu tun! (ganz sicher kann man sich ja nie sein!)