2012-06-30 8 views
5

schreiben Funktionsaufrufe von mehreren Threads auf den gleichen Sockelist es sicher zu schreiben Funktion in GNU C mit mehreren Threads verwenden

ist es sicher? Möchten wir eine Synchronisation zwischen ihnen hinzufügen? Wird es fro Probleme verursachen wie Anwendung Schreib verzögert zu werden/von der Netzwerkschicht auf der Anwendungsschicht lesen

Wir GNU C++ Bibliotheken GCC 4 auf Linux Redhat Enviornment verwenden

Dies ist ein Server-Side-Verfahren, bei dem Es gibt nur 1 Socket-Konnektivität zwischen Server & Client Server & Client sind auf 2 verschiedenen Maschinen Daten werden vom Server zum Client Client an Server

gesendet

Problem 1-Wenn Server Daten an die Client-Seite senden (Mehrere Threads schreiben dat a to client Side durch den gleichen Single Socket) Aber Daten Writen von einigen der Threads sind nicht auf Client-Seite gegangen es ist nicht einmal in den Netzwerk-Layer der gleichen Maschine gegangen (Tcpdump hat diese Daten nicht)

Problem 2-wenn Client Senden von Daten an Server-Daten Senden von Client wird in der Server-TCPdump nicht für die Server-Anwendung empfangen, die aus dem Socket von einem einzigen Thread mit einem "lesen" & "wählen" Funktionen in einer Schleife

Wir konnten das Muster des Auftretens dieser Probleme nicht identifizieren. Wir denken, dass dies passiert, wenn so viele Mehrfach-Threads in denselben Socket geschrieben werden. Wir sind nicht synchronisierte Schreibfunktion, in der Hoffnung, dass OS die Synchronisation verarbeitet

+0

Es ist "sicher" in dem Sinne, dass Ihr Programm wohlgeformt ist, aber die Ergebnisse, die Sie auf Ihrem Socket sehen, sind möglicherweise nicht das, was Sie erwarten. –

+0

@KerrekSB: das ist ein merkwürdiger Kommentar. Jedes Thread-unsichere Programm könnte in diesem Sinne als "sicher" bezeichnet werden, nein? –

+0

@NedBatchelder: Sicher nicht. Zum Beispiel ist eine Funktion, die von einem statischen Puffer für ihre interne Zustandsspeicherung abhängt, einfach * nicht * thread-sicher, und ein Programm, das es mehrere Male gleichzeitig aufruft, ist nur schlecht definiert. Im Gegensatz dazu ist ein Programm, das gleichzeitig 'write' aufruft, nicht automatisch schlecht definiert. –

Antwort

0

Es ist nicht sicher, write() aus mehreren Threads zu verwenden. Es gibt keine Garantie, dass die Ausgabe nicht zusammen gemischt wird. Ein Schreibvorgang könnte die Hälfte seiner Bytes in den Socket schreiben, dann könnte ein anderer Schreibvorgang beginnen, Bytes zu setzen. Wenn Sie sicher sein müssen, dass jeder Schreibvorgang zusammenhängend geschrieben ist (und es ist schwer vorstellbar, diese Garantie nicht zu benötigen), dann benötigen Sie eine Sperre oder eine andere Synchronisationsmethode.

+0

danke Ned. Wird es oben genannte Probleme verursachen? – samira

+0

@samira: Es könnte sicherlich die Probleme verursachen, die Sie beschrieben haben, aber es ist unmöglich zu sagen, ob die Synchronisation die Ursache ist. –

+1

Während des Zugriffs auf die Funktion können Sie Mutex verwenden, so dass nur ein Thread gleichzeitig auf die Funktion zugreift ... – shofee

1

write() ist ein Systemaufruf, keine Bibliotheksfunktion, und Systemaufrufe sind im Allgemeinen garantiert atomar.

+3

Wahr und nicht wahr. Der Systemaufruf ist garantiert atomar (und "sicher" in einem Sinne, dass er Ihre Daten weder abstürzen noch beschädigen wird), aber es gibt keine Garantie, dass Daten, die gleichzeitig (atomar) von zwei Threads gesendet werden, atomisiert übertragen werden: [interest read] (http://www.almaden.ibm.com/cs/people/marksmith/sendmsg.html). Beachten Sie auch, dass 'write' und' send' technisch weniger schreiben dürfen, als Sie verlangen. In diesem Fall müssen Sie mit einer zweiten Schreiboperation fortfahren, die sowieso die ganze Atomarität einbüßt. – Damon

0

Es wäre nicht spezifiziert, welcher write Aufruf zuerst abgeschlossen wird. Ein Kontextschalter könnte jeden der beiden Schreibvorgänge bei dem ersten Befehl anhalten. Dies kann zu einer willkürlichen Reihenfolge führen. Es gibt nichts write oder der Kernel kann das tun. Es ist ein grundlegendes Problem.

Ihre Daten werden in einer nicht spezifizierten Reihenfolge geschrieben, die für Sie wahrscheinlich nicht akzeptabel ist.