ist winsock2-thread-safe?

Schreibe ich eine kleine 3 Server und 1 client-Programm. die 2 Server senden von tcp-Nachrichten und der Letzte sendet UDP-Datagramme mit winsock2.

Frage ich mich, ob ich das machen kann simulanious recvfrom() durch die Verwendung von threads (OpenMP oder boost::threads), so dass 2 threads hören von der gleichen Steckdose am gleichen port zur gleichen Zeit.

Bin ich mit VC++ 2010 auf windows7.

Danke für Eure Hilfe.

  • Nein, sockets sind nicht threadsicher ist, müssen Sie ein socket pro Gewinde, jedoch mit Hilfe der windows-Meldungsschleife, die Sie Benachrichtigen können, ein thread aus einem anderen und Umgekehrt, threads selbst können message-loops.
  • "TCP-Nachrichten" können fragmentiert werden; TCP ist ein bytestream-Protokoll. Wie würden Sie sich mit einer Nachricht, die Hälfte erhielt von einem thread, und die Hälfte von den anderen? Die Tatsache, dass es nicht möglich ist, schützt Sie gegen die grundlegenden design-Fehler. Erhalten und wieder zusammenbauen, die Nachrichten in einem thread (das ist nicht teuer) und dann der Versand die ganze Nachricht zur weiteren Verarbeitung an andere threads.
  • Vielen Dank für Ihre Antworten. Ich werde erwägen Sie die Verwendung einer socket pro Gewinde.
  • Nur ein Hinweis, für TCP es in der Regel nicht sinnvoll, gleichzeitig Aufruf recv für den gleichen sockel, aber für UDP-es ist völlig in Ordnung.
  • zwei blockierende Aufrufe auf demselben thread ist eine seltene Erkrankung (denken Sie, wie könnte man das Problem möglicherweise recv, in der Regel aus einem thread, der thread ist bereits fest auf recv) und MS-Dokumentation sagt, das Ergebnis wäre Undefiniertes Verhalten, im Gegensatz zu einer gut definierten Verhalten der Rücksendung WSAEINPROGRESS in anderen Fällen. Ich bin wirklich daran interessiert zu wissen, wie es für Sie funktioniert.
  • Ich habe versucht zu laufen, zwei recvfrom() in zwei threads und es nicht funktioniert, weil es sein muss WSAStartup () - Aufruf in jeder Aufgabe.
  • WSAStartup müssen nicht genannt werden, indem jeder thread eines Prozesses. Es ist genug, um erfolgreich nennen es einmal in einem Prozess. Es sei denn, die zwei Fäden, die Sie erwähnt sind in verschiedenen Prozessen.

InformationsquelleAutor ezzakrem | 2012-12-21
  1. 7

    Ja, Steckdosen sind thread-sicher, aber Sie müssen vorsichtig sein. Ein gemeinsames Muster (bei Verwendung von blocking IO) ist ein thread empfangen von Daten auf einem socket und einem anderen thread das senden von Daten auf der gleichen Steckdose. Mit mehreren threads empfängt Daten von einem socket ist in der Regel gut für UDP-socket, aber macht nicht viel Sinn für TCP-sockets, die meisten der Zeit. Es ist eine Warnung in der Dokumentation für Sie wsarecv:

    Sie wsarecv sollte nicht aufgerufen werden, über die gleiche Buchse gleichzeitig aus
    verschiedene threads, weil es kann dazu führen, dass unvorhersehbare Puffer
    um.

    Aber dies in der Regel nicht aus, keine Sorge, wenn Sie mit UDP und das Protokoll ist zustandslos.

    Beachten Sie auch, dass die WSAEINPROGRESS Fehler-code bezieht sich hauptsächlich auf Winsock 1.1:

    WSAEINPROGRESS: EINEN blockierenden Windows-Sockets 1.1 Anruf getätigt wird, oder der service-provider ist immer noch der Verarbeitung einer callback-Funktion.

    Sowie die Beschreibung der WSAEINPROGRESS weitere Staaten:

    Vorgang jetzt in Bearbeitung.

    Ein blockierungsvorgang wird momentan ausgeführt. Windows Sockets erlaubt nur einen einzigen blockierungsvorgang pro task oder thread—hervorragend sein, und wenn eine andere Funktion aufgerufen wird (oder nicht, ob es Referenzen, oder ein anderes socket) die Funktion schlägt fehl mit dem Fehler WSAEINPROGRESS.

    Beachten Sie, dass diese Gespräche über einen einzigen blockierungsvorgang pro task oder thread.

    Darüber hinaus gibt es eine zusätzliche Warnung in der Dokumentation für Sie wsarecv:

    Ausstellung von einem anderen blockiert Winsock-Aufruf innerhalb einer APC unterbrochen, die eine anhaltende Blockierung Winsock-Aufruf auf dem gleichen thread führt zu undefiniertem Verhalten und darf niemals versucht werden, durch die Winsock-clients.

    Aber abgesehen von diesen Warnungen sollten Sie in Ordnung sein.

    Update: fügen Sie einige externe Verweise:
    alt.winsock.Programmierung: Ist die socket-thread-safe?
    und Winsock Programmer ' s FAQ: Ist Winsock-thread-safe?

    • Wir danken Ihr für all diese klaren Informationen. So ist es möglich, zwei Sie wsarecv auf die gleiche Buchse in zwei threads für UDP. So bekomme ich Fehler WSAEINPROGRESS nur, wenn ich zwei nennen blockierenden Operationen in den thread und nicht das ganze precess. Das ist eine gute Nachricht, da habe ich ein recv() in jedem thread. Eine andere Frage, sir. Hätte ich zwei UDP-Quellen, kann ich Daten aus diesen Quellen mit einem Gewinde und einer Steckdose (unter der Annahme, dass ich den gleichen port verwenden)?
    • Für UDP, die Sie normalerweise verwenden würden, recvfrom, um die Daten und der peer-Adresse und port-Nummer, so können Sie senden die Antwort zurück, wo die Anfrage kam. Da es keine Verbindung, jedenfalls ist es egal, ob jedes Paket kommt vom gleichen Absender, oder einen anderen.
    InformationsquelleAutor cmeerw
  2. 1

    Winsock erlaubt nur eine blockierende IO-Anruf auf einem sockel. Mehr als ein blockierender Aufruf aus dem anderen thread würde am Ende mit "WSAEINPROGRESS" Fehler. http://msdn.microsoft.com/en-us/library/windows/desktop/ms740668%28v=vs.85%29.aspx#WSAEINPROGRESS.

    Wenn Sie möchten, um die gleichzeitige E /a-Anforderung, die Sie könnten versuchen, mithilfe von asynchronen IO oder überlappende E /a - (im windows-Jargon). Aber ich denke, Sie würde wollen, dass die gleichzeitige Verarbeitung von Daten mehr als gleichzeitige Lesen von Daten. In dem Fall könnte man ein thread Erteilung IO-Anforderungen und andere für die Verarbeitung.

    • Ich bezweifle sehr, dass - die Dokumentation besagt, "einen einzigen blockierungsvorgang pro task oder thread". Die Beschreibung für Sie wsarecv heißt es weiter: "die Ausstellung von einem anderen blockiert Winsock-Aufruf innerhalb einer APC unterbrochen, die eine anhaltende Blockierung Winsock-Aufruf auf dem gleichen thread führt zu undefiniertem Verhalten und darf niemals versucht werden, durch die Winsock-clients."
    • Die Dokumentation spricht über den Fall, wo APC "Asynchronous procedure call" würde auf dem gleichen thread ausgeführt, die ausgestellt die Sperrung nennen. Als APC würde, die ausgeführt direkt bevor ein thread wieder aufgenommen wird - ein user-mode APC, nicht bekommen eine chance, um zu führen - und wenn es Probleme eine andere blockierende socket-Aufruf ist das Verhalten undefiniert. Zu geben, eine Perspektive code, die Dokumentation wird sprechen über einige code ausführen auf dem gleichen thread, in dem recv oder Sie wsarecv noch ausgeführt wird, ist nur dann möglich, wenn hervorragende APC in Warteschlange für den thread.
    • Ja, und der Punkt ist, dass mehr als ein blockierender Aufruf ist nur ein problem auf dem gleichen thread. aber nicht, wenn mehrere threads (einen blockierenden Aufruf pro thread ist in Ordnung).
    InformationsquelleAutor nanda
Schreibe einen Kommentar