Zwei Threads, ein Socket = Probleme?
-
In meinem Programm wird ein neuer Thread gestartet, welcher einen TCP/IP socket initialisiert, genau eine verbindung akzeptiert und ständig von ihm liest (recv). Der Thread des Hauptprogrammes muß auf den geöffneten socket allerdings auch für Schreibzugriffe/send() benutzen können. Ich frage mich nun, ob ich den socket als gemeinsam genutzte Ressource über eine critical-section synchroniseren muß. Wenn ja, klappt das überhaupt? Immerhin würde der zweite Thread beständig von dem socket lesen und ihn doch somit permanent blockieren..
-
Serethos schrieb:
In meinem Programm wird ein neuer Thread gestartet, welcher einen TCP/IP socket initialisiert, genau eine verbindung akzeptiert und ständig von ihm liest (recv). Der Thread des Hauptprogrammes muß auf den geöffneten socket allerdings auch für Schreibzugriffe/send() benutzen können. Ich frage mich nun, ob ich den socket als gemeinsam genutzte Ressource über eine critical-section synchroniseren muß. Wenn ja, klappt das überhaupt? Immerhin würde der zweite Thread beständig von dem socket lesen und ihn doch somit permanent blockieren..
Also ist der socket(handle) im child process? Eieiei, so würde ich es net machen.
Also normalerweise macht man es mit select() statt mit threads. Da ich aber genau so ein Sturkopf bin, nutze ich auch threads.
Also leg mal im Hauptprocess den socket an. recv() lieber im Hauoptprocess und send() lieber im child process. Fall das gegenüberliegende socket geschlossen wird, kannst du dann sofort daruaf reagieren und deine anwendung auch beenden.Und achte darauf, dass du ZUERST den socket anlegs bevor du listen() etc aufrufst.
MfG, Klugscheisser
-
Leider habe ich die Wahl nicht: Die Geschichte wird in einer DLL ausgeführt, welche als plugin von einem Programm benutzt wird. Da die Anwendung selbst für Gui und Programmlogik nur einen(!) Thread benutzt, würde das accept() im Hauptthread die komplette Gui blocken und die Hauptschleife selbst blocken.
-
Welches Betriebssystem benutzt du?
Ich glaube nicht, dass das Probleme geben könnte, da es Lesen und Schreiben im Grunde zwei getrennte Dinge sind für den Kernel und die Hardware ja eh über den Treiber synchronisiert wird.
-
Win XP
-
Ja, dann ist es so wie rüdiger es gesagt hat.
-
Serethos schrieb:
Win XP
Ich verschiebe es mal ins WinAPI-Forum, da die Leute dort sicher mehr Ahnung haben von den internen Angelegenheiten in Windows (und Winsocks sind ja ein Teil der WinAPI)
-
Dieser Thread wurde von Moderator/in rüdiger aus dem Forum Rund um die Programmierung in das Forum WinAPI verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
Ich bin mir relativ sicher, daß der Socket nicht syncronisiert werden muß,
da send und recv den Wert aus dem Socket immer nur auslesen und es beim
lese-lese Zugriff keine Probleme geben dürfte.
(Außerdem ist der Socket, wie ja auch 'rüdiger' sagt, sowieso Treadsicher)Ich bin noch nen größerer Sturkopf und habe 2 Thread benutzt einen für recv
(Der blockiert ja so schön und braucht dann keine CPU Power, wenn nichts ansteht)Und einen Thread für send, dieser sendet und legt sich dann schlafen (ist ganz einfach zu machen). Wenn wieder was zum Senden ansteht, wecke ich ihn halt.
-
Vielen Dank für Eure Antworten. Ich werd mir nun also keine Sorgen machen, das bestätigt auch meine bisherigen Erfahrungen beim Rumexperimentieren.
-
Wenn du WinAPI proggst (sockets laufen ja sowohl unter LINUX als auch unter WINDOWS) kannst du auch auf die WinInet-Funktionen zurückgreifen (WSAxxx). Die sind bereits in Threads gepackt. Immer wenns 'was neues gibt' bekommst du dann ne bestimmte Nachricht
.