qtforum.de

Hallo!

Thread-sicher bedeutet doch nur, dass verhindert wird schreibend auf ein Objekt zuzugreifen, während es von einem anderen Thread ausgelesen wird richtig?

Folgendes dürfte also, ohne die Verwendung eines Mutex o.ä., thread-safe sein?:
- Thread A und B greifen gleichzeitig lesend auf dieselben Daten (teilweise Qt-Klassen) von Thread C zu, während logisch ausgeschlossen wird, dass während dieser Vorgänge die Daten beschrieben werden.
- Thread A und B greifen gleichzeitig schreibend auf unterschiedliche Daten von Thread C zu, während logisch ausgeschlossen wird, dass während dieser Vorgänge die Daten von jeweils anderen Threads ausgelesen/bearbeitet werden.

Also kurz gesagt hat die Verwendung von QMutex o.ä. irgend einen weiteren Grund, außer lese-/schreib-Überschneidungen zu verhindern?
Und außerdem würde ich gerne wissen ob es schneller/effizienter ist auf Objekte im eigenen Thread zuzugreifen als auf Objekte anderer Threads (wenn diese nicht durch einen Mutex angehalten wurden)?

Bin für jede Anmerkung dankbar!!
Mfg FaS

Das stimmt so nicht ganz.
Threadsafe ist ein Stück Software dann, wenn es quasi-gleichzeitig durch mehrere Threads benutzt werden kann, ohne dass es zu ungewollten Rückwirkungen kommt.

Eine gewollte Rückwirkung wäre z.B., wenn der Zugriff auf den Drucker per Mutex nur jeweils für einen aufrufenden Thread erlaubt, und die anderen Threads so lange blockiert werden.

Eine ungewollte Rückwirkung wäre das gleichzeitige lesen/schreiben einer Variable, vor allem aber auch Sitzuationen wie z.B.: Thread 1 beschreibt eine Variable "Vorname" mit "Max", während Thread 2 eine andere Variable "Nachname" mit "Musterfrau" beschreibt. Das Gesamtergebins "Max Musterfrau" ist unsinnig, auch wenn keine direkte Kollision erfolgt ist! Objektvariablen dürfen in solchen Fällen nicht statisch sein - sprich, der Code muss reentrant sein.

Mutices und Semaphoren müssen immer so eingesetzt werden, dass kritische Bereiche (critical sections) damit vollständig abgeschirmt werden - das ist oft mehr als nur das lesen/schreiben einer einzelnen, gemeinsamen Variable.

Ja gut aber in meinem Fall meine ich mit "Daten" ja voneinander unabhängige Elemente. Fälle wie dein angesprochenes "Max Musterfrau" würden also nicht auftreten. Diese Dinge hatte ich ja mit meinen "logischen Ausschlüssen" ausgeschlossen .
Also für meine 2 Beispiele die ich anfangs nannte dürfte das ohne Mutexes funktionieren? (gleichzeitiges lesen von denselben Daten aus versch. Threads und schreiben von Daten in einem anderen Thread ohne QMutex)?

Ich verstehe dabei nicht, was Du mit "logische Ausschlüsse" meinst... irgendwann müssen die Daten ja einmal bverschrieben werden, vermutlich durch einen der aufrufenden Threads.
Wenn Deine Applikation dafür sorgt, dass hierbei keine Kollisionen entstehen können - schön und gut. Threadsafe ist der Code trotzdem nicht - wenn Du ihn in einer anderen Applikation einsetzt bzw. nächstes Jahr an Deiner akutellen Applikation Änderungen vornimmst, fliegt Dir das Ding um die Ohren. Wenn es sich also nicht um Wegwerfcode handelt, dann gönn Dir den Overhead von Locking-Mechanismen, wo immer ein Zugriffskonflikt möglich ist.

Gut danke, wollte nur wissen ob threadübergreifende Zugriffe grundsätzlich geschützt werden müssen, nicht nur um solche inhaltlichen Kollisionen zu verhindern welche bei mir nicht auftreten (-> Max Musterfrau), sondern aus anderen, technischen (low-level) Gründen. Z.B: "man kann nicht x auslesen, wärend ein anderer thread gerade dabei ist x auszulesen" oder "x des threads A kann nicht beschrieben werden, da y desselben threads gerade beschrieben wird". Soetwas existiert also nicht, dann ist das ja geklärt.

Und zu meiner letzten Frage nochmal: Ist es schneller/effizienter auf Variablen im eigenen Thread zuzugreifen als auf Variablen in anderen Threads?

Danke,
FaS

FaS hat geschrieben:Und zu meiner letzten Frage nochmal: Ist es schneller/effizienter auf Variablen im eigenen Thread zuzugreifen als auf Variablen in anderen Threads?

Was verstehst Du unter Zugriff auf Variablen anderer Threads? Eine Variable gehört an sich keinem bestimmten Thread an, schon gar nicht solche, die in mehreren Threads sichtbar sind (die sind statisch).

Möglicherweise hat jeder Thread seinen eigenen Speicherbereich und bei Fremdzugriffen werden dann vielleicht diverse Tests durchgeführt, auf Threadaktivitäten getestet oder was auch immer keine Ahnung darum frag ich ja. Was passiert denn intern wenn man Qt-Objekte mit moveToThread() einem anderen Thread zuordnet? Außer dass dann ein ggf. vorhandener event loop dort ausgeführt wird?
Wenn nichts dann wäre ja alles geklärt. Threads haben dann also rein garnichts mit der Speicherverwaltung/-reservierung/was auch immer zu tun, sie dienen einzig und allein der Möglichkeit der pseudeo-parallelen Befehlsabarbeitung? Und es ist egal welcher Thread gerade aktiv ist, nichts verändert sich und jede Heap-Speicheranforderung beispielsweise führt zum selben Ergebnis?
Wenn nein, bitte genau das alles möchte ich wissen. Wenn das alles im Normalfall nicht zutrifft, dann vielleicht nachträglich eingebaut speziell bei bestimmten Qt-Klassen wo explizit die Threadzugehörigkeit abgefragt wird oder z.B. bei nicht-GUI-Threads spezielle Puffer verwendet werden welche nach und nach vom GUI-Thread bearbeitet werden oder son Mist? Ich denke da z.B. an reentrant Funktionen wie QList..

FaS hat geschrieben:Möglicherweise hat jeder Thread seinen eigenen Speicherbereich und bei Fremdzugriffen werden dann vielleicht diverse Tests durchgeführt, auf Threadaktivitäten getestet oder was auch immer keine Ahnung darum frag ich ja.

Jeder Thread eines Prozesses besitzt zwar einen eigenen Stack, der Heap dagegen ist der selbe. Zu einer Speicherschutzverletzung kommt es, wenn Du versuchst, auf den heap eines anderen prozesses zuzugreifen.

FaS hat geschrieben:Was passiert denn intern wenn man Qt-Objekte mit moveToThread() einem anderen Thread zuordnet? Außer dass dann ein ggf. vorhandener event loop dort ausgeführt wird?

Das betrifft AFAIK nur die Verarbeitung der Events, die nur in jeweils einem Thread stattfinden kann.

FaS hat geschrieben:Und es ist egal welcher Thread gerade aktiv ist, nichts verändert sich und jede Heap-Speicheranforderung beispielsweise führt zum selben Ergebnis?

So isses.

Gut danke OscarWild!
MfG, FaS