boost threads
-
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????
-
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
-
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!
-
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)
-
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!)
-
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.
