Threadsafe?
-
Ich habe ein fenster, von welchem mehrere threads unabhängig voneinander z.b. den titel ändern (also SetWindowText(m_hwnd) ) aufrufen.
Nun meine Frage:
Sind Funktionen wie diese threadsafe, oder darf jeweils nur ein thread auf den handle zugreifen?
Welche Funktionen kann man ohne bedenken threadübergreifend nutzen und von welchen sollte man die finger lassen (laut google sind die GDI funktionen zum beispiel nicht threadsafe).
Außerdem interessiert mich was passiert wenn mehrere threads nachrichten an das fenster senden. Kann es dann zu "komischen überscheidungen" kommen?
-
Laut Doku verändert SetWindowText den Fenstertext nicht selbst, sondern sendet lediglich eine entsprechende Nachricht an das Fenster.
-
Belli schrieb:
Laut Doku verändert SetWindowText den Fenstertext nicht selbst, sondern sendet lediglich eine entsprechende Nachricht an das Fenster.
Und das geht in Windows über Queues. Hört sich Thread-safe an. Jedenfalls was die Paramter angeht. Aber der String, auf den der Pointer zeigt, darf wohl erst verändert werden, nachdem der Text vollständig im Fenster gelandet ist. In der WinApi-Doku müsste das Verhalten beschrieben sein.
-
Z schrieb:
Aber der String, auf den der Pointer zeigt, darf wohl erst verändert werden, nachdem der Text vollständig im Fenster gelandet ist.
Bei PostMessage() ja, denn da wird die message gequeued. Bei SendMessage() wird die message noch während dem Aufruf processed.
Denglisch
-
Laut Doku verändert SetWindowText den Fenstertext nicht selbst, sondern sendet lediglich eine entsprechende Nachricht an das Fenster.
okay, also der zugriff auf die message-queue des fensters ist threadsafe?
Dann dürfte ich ja keine probleme bekommen wenn ich zum beispiel den titel ändere und weil immer die nächste nachricht erst verarbeitet wird, wenn die aktuelle verarbeitet ist kommt es auch nicht zu "überkreuzungen" und alles läuft schön geregelt nacheinander ab ?!Ich gucke nochmal genau in die doku, aber allgeimein... hab ich das jetzt grob richtig verstanden?
-
gamer8o4 schrieb:
Laut Doku verändert SetWindowText den Fenstertext nicht selbst, sondern sendet lediglich eine entsprechende Nachricht an das Fenster.
okay, also der zugriff auf die message-queue des fensters ist threadsafe?
Wenn die Funktion einfach eine Message postet, dann wird das eigentliche Ändern ja nicht im Kontext des Threads durchgeführt, der die Funktion aufruft, also threadsafe, ja, das wollte ich damit sagen.
Allerdings habe ich nicht bedacht, dass, wie Hi richtig schrieb, eine Message via SendMessage sehr wohl im Kontext des aufrufenden Threads abgearbeitet wird, also eher nicht threadsafe ...
-
Hi schrieb:
Z schrieb:
Aber der String, auf den der Pointer zeigt, darf wohl erst verändert werden, nachdem der Text vollständig im Fenster gelandet ist.
Bei PostMessage() ja, denn da wird die message gequeued. Bei SendMessage() wird die message noch während dem Aufruf processed.
Denglisch
Das ist nicht korrekt. SendMessage in einen anderen Thread verhält sich so wie PostMessage, außer dass sie sich nicht hinten einreihen, sondern in diesem Thread möglichst zügig abgehandelt werden.
-
Hmm, aber MSDN schreibt zu SendMessage "The sending thread is blocked until the receiving thread processes the message".
-
Es kann sich nicht gleich verhalten, denn SendMessage liefert einen Rückgabewert. Wo sollte der herkommen, wenn die Nachricht nicht direkt verarbeitet würde?
-
Hi schrieb:
Hmm, aber MSDN schreibt zu SendMessage "The sending thread is blocked until the receiving thread processes the message".
Jo, habs auch noch mal genau nachgelesen. Ich ändere meine Meinung noch einmal: Es hört sich so an, als ob die Message im Kontext des aufgerufenen Threads bearbeitet wird, ich sage also: Threadsafe.
-
Jaja, ihr habt ja Recht, ich hatte bei SendMessage an einen anderen Thread ein Warnzeichen im Kopf und das war nicht durch nicht-sofortige Abarbeitung entstanden, sondern um das ideale Potential für Deadlocks, mal abgesehen vom Blockieren.