2016-07-12 11 views
2

So einfach diese Frage ist, habe ich nichts von Googling gefunden. Ist es sicher, gleichzeitige Aufrufe an das Linux-System zu tätigen, wie zum Beispiel socket() auf mehreren Threads bei (was könnte sein) zur gleichen Zeit? Gewährleistet der Kernel speziell die Thread-Sicherheit für , connect() und/oder send()?Gleichzeitige Systemaufrufe in Linux

Wenn nicht, warum nicht? Ich würde gerne mehr über dieses Thema erfahren und warum Systemaufrufe Thread-sicher sind oder nicht.

Mein Hauptanliegen hier ist wirklich, dass socket() nicht einen doppelten oder ungültigen Dateideskriptor zurückgibt, wenn von anderen Threads aufgerufen. Ich werde in meinem Fall nicht gleichzeitig an dieselbe Steckdose anschließen oder schreiben.

+0

Was bedeutet Thread-Sicherheit in dieser Situation? – immibis

Antwort

4

Ist es sicher gleichzeitige Anrufe auf dem Linux-System, wie Aufruf socket() auf mehrere Threads (was auch sein mag) gleichzeitig zu machen?

Ja, sie sind threadsicher. Obwohl ich nicht sicher bin, ob es nach dem POSIX-Standard ist oder nicht.

Insbesondere garantiert der Kernel Thread-Sicherheit für socket(), connect() und/oder send()?

Gemäß THIS Link, ja. Es besagt, dass Sperren intern verwendet werden, was bedeuten würde, dass Ihre send Operation serialisiert wäre, aber nicht in einer bestimmten Reihenfolge.

Antwort der Frage aktualisiert Teil:

hier Mein Hauptanliegen ist es wirklich, dass socket() wird nicht zurückkehrt einen doppelte oder ungültigen Deskriptordatei, wenn aus verschiedenen Threads aufgerufen.

Keine Sorgen hier. Das Betriebssystem stellt sicher, dass die Dateideskriptoren für den Socket nicht dupliziert werden.

+1

" Wirst du * das System zum Absturz bringen? * Nein. "Könnten deine Threads 'Rennen' und sonst 'konkurrieren' miteinander, so dass Sie völlig unvorhersehbare Ergebnisse erhalten ? Definitiv Ja. –

+0

Ja, gültige Punkte. Aber die Race-Bedingung wäre nur in STREAM-Protokollen beobachtbar, UDP, das nur einen Schuss hat, leidet nicht unter den Sendepufferdaten. – Arunmu

+0

@MikeRobinson in diesem Fall verwende ich TCP-Sockets, und schreibe nie gleichzeitig in die gleiche Steckdose. Mein Anliegen ist, 'socket()' aufzurufen und einen doppelten oder ungültigen Dateideskriptor zu erhalten. Solange das garantiert nicht passiert, bin ich glücklich. – RogueCSDev

0

"Werden Sie das System abstürzen?"   Nr

„Might Threads‚Rasse‘und ansonsten‚konkurrieren‘miteinander, so dass Sie gründlich unberechenbar und un-reproduzierbare Ergebnisse zu erhalten?   Definitiv ja.

Der Kernel im Allgemeinen Ansichten Ressourcen (wie Steckdosen ...), wie vom Prozess gehört wurde zu dem alle Fäden gehören.   Und wenn ein bestimmte Anruf „blockieren“ ist, es wird wahrscheinlich den Prozess blockieren.

Schließlich Buchse Aktionen wie send, wissen nicht wirklich Nutzen aus der Verwendung von Threads trotzdem, weil Pakete und erhielten durch einen (vergleichsweise langsam ...) eindrähtig, einen zu einem gesendet werden Zeit im Millisekundenbereich. Eine einfache select() Polling-Loop funktioniert in der Regel gut. "Komplexität wird nicht neu bezahlt."

+0

Danke. Ich werde darüber nachdenken, meine Anwendung neu zu gestalten. – RogueCSDev

+0

Greifen Sie einfach auf den Server-Code "von der Stange" von GitHub oder aus der beigesteuerten Bibliothek Ihrer Programmiersprache. Benutze es oder kopiere es direkt. –

+0

Diese Antwort ist irreführend - insbesondere blockiert ein blockierender Systemaufruf nicht den gesamten Prozess (zumindest nicht auf einem modernen Betriebssystem). Es blockiert nur den Thread, der den Anruf ausgelöst hat. Auch viele Programme verwenden mehrere Threads zusammen mit Sockets gut. Es ist schwieriger, Recht zu bekommen als ein einzelner Thread, aber es ist ein vollkommen akzeptabler Ansatz, wenn der Programmierer weiß, was er tut, und es wird häufig verwendet. Ob dies im Vergleich zu einem multiplexed-single-thread-Ansatz von Vorteil ist, hängt stark davon ab, was * sonst * der Thread tun muss, außer Senden/Empfangen. –

Verwandte Themen