boost threads

David_pb

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

David_pb

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)

David_pb

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.

Simon2

Hi,

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

... so eine Art "kill" ?

Gruß,

Simon2.

LordJaxom

Auch einfach:

Thread 1:

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

Thread 2:

bRun = false;

:p

Simon2

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.

LordJaxom

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

Simon2

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.

Vellas

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

hustbaer

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

Entenwickler

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

LordJaxom

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)

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

Entenwickler

Multiscreener schrieb:

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!

LordJaxom

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)

Entenwickler

LordJaxom schrieb:

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!)

Simon2

Entenwickler schrieb:

LordJaxom schrieb:

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!)

Ich wüsste nicht, was daran falsch sein sollte.
Man darf natürlich "Serialisierung der Zugriffe" nicht mit "Serialisierung eines Objekts" (wie mittels einer serialize()-Methode) verwechseln. Vom Wort her bedeutet "Serialisierung" "in Reihe bringen" .... passt also auch (sogar noch besser als bei der "Serialisierung eines Objekts").

Diese Verwendung ist in meinem Umfeld (hier in der Firma, mit Kunden, Anbietern, Beratern, ...) absolut üblich. Es wird zwar bisweilen auch der Ausdruck des "Synchronisierens" verwendet, der ist allerdings eigentlich NOCH unschärfer, da es gerade NICHT um die "Herstellung einer Gleichzeitigkeit" geht, sondern um ihre Vermeidung. Und da "Synchronisierung" in noch mehr Zusammenhängen verwendet wird, nehme ich lieber "Serialisierung".

Gruß,

Simon2.