Heim  >  Artikel  >  Backend-Entwicklung  >  Was tun, wenn die PHP-Dateisperre blockiert ist?

Was tun, wenn die PHP-Dateisperre blockiert ist?

王林
王林Original
2019-09-18 13:04:483353Durchsuche

Was tun, wenn die PHP-Dateisperre blockiert ist?

Was ist ein Deadlock?

Jeder, der sich mit Betriebssystemen beschäftigt hat, kennt das Konzept des Multithreadings. Der Zugriff auf öffentliche Ressourcen in mehreren Threads erfordert das Sperren der Ressourcen. Nachdem der Zugriff abgeschlossen ist, lösen Sie die Sperre. Wenn die Sperre nicht aufgehoben wird, kann der nächste Thread bei der Anforderung der Ressource nie die Ressourcensperre erhalten, sodass der Thread blockiert ist. Ist CGI also ein Deadlock, der durch den Multithread-Zugriff auf öffentliche Ressourcen verursacht wird? Die Antwort ist NEIN.

1. CGI ist ein Single-Threaded-Prozess und kann über ps angezeigt werden. (Der Prozessstatus Sl ist ein Multithread-Prozess).

2. Selbst wenn es sich um Multithreading handelt, tritt der Deadlock auf, wenn die Zeitfunktion in glibc während des Herunterfahrens von PHP aufgerufen wird, und wird nicht durch das PHP-Modul . Die zeitbezogenen Funktionen in glibc sind threadsicher und verursachen keinen Deadlock.

Was verursacht den Deadlock?

Durch die Analyse des Deadlock-Mechanismus unter Linux haben wir festgestellt, dass neben Multithreading auch Signalverarbeitungsfunktionen einen Deadlock verursachen können. Ist der CGI-Deadlock also auf die Signalverarbeitung zurückzuführen? Lassen Sie mich vorher einen Gedanken vorstellen.

Wiedereintritt und Signalsicherheit von Funktionen

Funktionswiedereintritt bedeutet, dass die Funktion unabhängig davon, wie oft sie eingegeben wird, normal ausgeführt werden kann und Ergebnisse zurückgibt. Sind threadsichere Funktionen also wiedereintrittsfähig? Die Antwort ist NEIN. Eine Thread-sichere Funktion erhält eine globale Sperre, wenn sie zum ersten Mal auf eine öffentliche Ressource zugreift. Wenn die Funktion nicht ausgeführt wurde und die Sperre nicht aufgehoben wurde, wird der Vorgang unterbrochen. Dann führt ein erneuter Zugriff auf die Funktion in der Interrupt-Verarbeitungsfunktion zu einem Deadlock.

Auf welche Art von Funktionen kann also in der Interrupt-Verarbeitungsfunktion zugegriffen werden?

Zusätzlich zu Funktionen, die keine globalen Sperren verwenden, können auch einige signalsichere Systemaufrufe verwendet werden. Der Aufruf einer anderen nicht signalsicheren Funktion hat unvorhersehbare Folgen (z. B. Deadlock). Weitere Informationen finden Sie unter Mannsignal. Bevor wir die Ursachen von Deadlocks analysieren, schauen wir uns zunächst den CGI-Ausführungsprozess an und analysieren, ob die Möglichkeit eines Deadlocks besteht.

PHP-CGI-Ausführungsablauf

Die Zeitfunktion in Glibc verwendet eine globale Sperre, um die Thread-Sicherheit der Funktion sicherzustellen, garantiert jedoch keine Signalsicherheit. Nach vorheriger Analyse vermuteten wir zunächst, dass der Deadlock darauf zurückzuführen war, dass der PHP-CGI-Prozess ein Signal empfing und dann eine nicht signalsichere Funktion im Signalhandle ausführte. Bevor der Hauptprozess unterbrochen wird, führt er die Zeitfunktion in glibc aus. Bevor die durch die Funktion erworbene Sperre aufgehoben wird, wird der Interrupt-Prozess gestartet. Während des Unterbrechungsprozesses wird auf die Zeitfunktion in glibc zugegriffen. Dies führte zu einem Stillstand.

Der Ausführungsprozess von PHP-CGI ist wie in der folgenden Abbildung dargestellt:

Was tun, wenn die PHP-Dateisperre blockiert ist?

Lösung:

Entfernen oder vereinfachen Sie die von qalarm registrierte Hook-Funktion zum Herunterfahren. Vermeiden Sie unsichere Funktionsaufrufe.

Der obige Inhalt dient nur als Referenz!

Empfohlenes Tutorial:

PHP-Video-Tutorial

Das obige ist der detaillierte Inhalt vonWas tun, wenn die PHP-Dateisperre blockiert ist?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn