Eventuell erinnert sich mancher Leser noch an sein Informatik-Grundstudium. Dort wurde dann ggfs. gelehrt, was man unter einer Äquivalenzrelation zu verstehen hat. Der Vergleichsoperator == erfüllt in PHP die Bedingungen einer solchen nicht (im Gegensatz zu ===). Diese drei Bedingungen lauten wie folgt:

• Reflexivität (z.B. a ist gleich zu sich selbst)
• Symmetrie (z.B. a ist gleich b und umgekehrt)
• Transitivität (z.B. a = b und b = c, dann ist a = c)

Schlagen wir den Bogen zu PHP. Dazu ein zunächst funktionierendes, kleines Beispiel für die einfache Gleichheitsrelation:

//Initialisierungen
$a = $b = $c = 5;

//Aequivalenzrelation?
var_dump($a == $a); //=> true =>Reflexivitaet
var_dump($a == $b && $b == $a); //=> true => Symmetrie
var_dump($a == $b && $b == $c && $a == $c);
//=>true => Transitivitaet

Das sieht doch soweit eigentlich ganz gut aus, aber:

//Initialisierungen
$a = false;
$b = '0';
$c = '';

//Aequivalenzrelation?
var_dump($a == $a); //=> true => Reflexivitaet
var_dump($a == $b && $b == $a); //=> true => Symmetrie
var_dump($a == $b && $b == $c && $a == $c);
//=> false => keine Transitivitaet!

Der letzte var_dump() liefert ein false, aufgrund von $a == $c. Denn in PHP ist der Leerstring ” unter Benutzung des einfachen Gleichheitsoperators ==, nicht gleich ’0′. Prüft man auf leere Strings, sollte man sich dieses Verhalten immer vor Augen führen. Für mich ist nämlich auch ’0′ ein korrekter String. Dies birgt so manche Gefahr. Ein…

if($str) { /* some code */ }

…sollte für Strings daher grundsätzlich tabu sein, wenn man ermitteln möchte, ob der jeweilige String einen Wert enthält – soweit man nicht explizit mit dem oben genannten Verhalten rechnet.

Aber wie richtig prüfen? Viele werden nun an isset() oder empty() denken. Nein, meine Lösung sieht so aus:

$mystring = ???;
if('' != $mystring) {
  /* some code here */
}

Diese Bedingung erfüllt meiner Meinung nach alles, was benötigt wird:

• einfacher Code, der niemanden verwirrt
• null wird korrekt behandelt
• Der Leerstring ” wird korrekt behandelt
• ’0′ wird als true interpretiert

Da $mystring bereits vorher gesetzt wurde, ist auch kein isset() nötig (dazu später noch mehr).

Implizite Typkonversion

Der Vorteil des obigen Codes ist die impliziete Typconversion – erzielt durch zwei, statt drei Gleichheitszeichen. Für den Vergleich müssen beide Seiten auf den selben Typ gebracht werden. D.h. die rechte Seite wird in diesem speziellen Fall (dazu später mehr) auf den Typ der linken, einen String gebracht. Das kann man mit einem kleinen Beispiel schnell nachvollziehen:

class T {
  public function __toString() {
    echo 'Konvertierung!';
    return 'test';
  }
}

$t = new T();
if('' != $t) {
  /* do something */
}

//Ausgabe: Konvertierung!

Demnach wird die Vergleichsvariable durch die Konvertierung zum String. Bei Nutzung von === wird die Typkonversion hingegen übergangen. Ist der Typ nicht der gleiche, wird der Rest der Prüfung nicht mehr durchgeführt.

Weiter oben hatte ich von einem “speziellen Fall” geschrieben. Denn die Konvertierungsvorschrift hängt von den Typen der Operanden ab:

• Sind beide Operanden Strings oder null, wird ein String-Vergleich durchgeführt.
• Ist einer der beiden Operanden ein boolscher Wert, wird der andere auf den Typ bool gebracht.
• In den anderen Fällen, werden die Operanden in Zahlen umgewandelt.

Zugegebenermaßen muss man sich nun noch über Arrays und wie in unserem obigen Fall über Objekte unterhalten. Letzere kann man aber eh nur nach bool oder String casten. Demnach macht eine Konvertierung zu String in unserem Beispiel den größten Sinn und widerspricht auch den obigen Regeln nicht. Denn keiner der Operanden ist vom Typ bool und in einen int/double/float kann das Objekt nicht umgewandelt werden – es bleibt nur der Typ string übrig.

Nun zu Arrays. Hier ist die Sache deutlich undurchsichtiger, nachdem Arrays in alle skalaren Typen gecastet werden können. Den String-Vergleich kann man aber schon mal ausschließen:

var_dump('Array' == array()); //=> false

Arrays sind bei Vergleichen aber sowieso eine Besonderheit. Auf ein true im Vergleich kann man nur kommen, wenn…

• …einer der Operanden ein bool ist.
• …man das Arrays mit null vergleicht, soweit es keine Werte enthält.
• …man das Array mit sich selbst vergleicht.

Wer sich die Sache nun noch genauer ansehen möchte, sieht sich am Besten mal die “Type Conversion Tables” an: http://php.net/manual/de/types.comparisons.php
Die dortige Auflistung kann man auf jeden Fall immer benutzen, wenn man sich unsicher ist. Objekt-Vergleiche werden hier allerdings nicht aufgelistet.

empty()

Ich weiß ja nicht wie es Euch so geht, aber ich finde empty() evil. Es hat das gleiche Problem wie ein if($str). Hier waren die PHP-Entwickler konsequent und haben auch ’0′ eingeschlossen. Beispiel:

$a = '0';
if(!empty($a)) { /* some code */ }

Leider landet man damit auch nicht in “some code”. Vielleicht reite ich ja ein wenig darauf herum, aber ’0′ ist für mich nunmal auch ein gültiger String und oftmals eine valide Benutzereingabe. empty() ist außerdem immer so eine Art blackbox. Was ist nochmal genau “empty”? – Wer muss da nicht des öfteren nachschauen? Das macht den Code somit weniger leser-/wartungsfreundlich.

Darüber hinaus ist empty ein Sprachkonstrukt und keine richtige Funktion. Es kann nur Variablen verarbeiten. Konstanten (hierbei spielt es keine Rolle, ob diese per “const” oder “define” deklariert wurden) können deshalb nicht an empty übergeben werden.

isset()

Dann wäre da noch isset(). Hierbei ist das Problem nicht ’0′, sondern der Leerstring ”. Scheinbar glauben noch immer viele Entwickler daran, isset() prüfe auf diesen. Das ist nicht der Fall. Ein…

if(isset($a)) { /* some code */ }

ist bei skalaren Werten und Arrays absolut identisch zu…

if(null !== $a) { /* some code */ }

und daher nicht mit einem String-Vergleich auf den Leerstring zu verwechseln (man beachte die 2 Gleichheitszeichen). Der Vergleich zwischen den beiden Codeschnipseln hinkt jedoch an zwei Stellen:

• isset() erzeugt im Gegensatz zu null !== $a keine Warnung – falls $a vorher im Code noch nie schreibend genutzt wurde.
• isset() kann mehere Parameter auf einmal berücksichtigen
• (isset() kann innerhalb von Objekten __isset() nutzen – daher habe ich “skalaren Werten und Arrays” geschrieben)

Der Vorteil der nicht ausgegebenen Warnung relativiert sich in einem Spezialfall aber wieder, wenn man sich folgendes Beispiel vor Augen hält:

$a = null;
var_dump($a);
var_dump(isset($a));
var_dump($b);
var_dump(isset($b));

Interessanterweise erzeugt der Zugriff auf $a keine Warnung, der auf $b schon. Gesetzt sind laut isset() dennoch beide Variablen nicht. Das muss wohl daran liegen, dass Variablen ab dem Zeitpunkt der ersten Zuweisung im Code in die Symboltabelle aufgenommen werden – selbst wenn deren Wert gleich null ist.

Ein weiterer Mythos besteht wohl durch den Namen der Funktion:

$a = null;
$b = $a;
var_dump(isset($b)); //->liefert false

Obwohl man laut dem Funktionsnamen von isset() eigentlich davon ausgehen möchte, dass $b gesetzt ist, wird false zurückgegeben. Für $b wurde doch eine Zuweisung durchgeführt!? $b ist jedoch laut isset() auch nach dieser nicht gesetzt. Wer es nicht glaubt, kann es gerne mal ausprobieren

Denke ich nun noch einmal an den String-Vergleich von oben, müsste aufgrund der neu erungenen Erkentnisse der Code also doch so lauten:

if(isset($mystring) && '' != $mystring) {
  /* some code here */
}

Ich vermeide diese Schreibweise dennoch. Das isset gehört für mich nur einfach an eine andere Stelle im Code. Wenn wir speziell $_POST/$_GET/$_REQUEST betrachten, können wir schlichtweg einfach nicht sicher sein, ob die Variable auch wirklich gesetzt ist. I.d.R. arbeite ich aber auch nicht mit $_POST[‘xyz'], sondern einer zentralen Methode, die diese Variable dann zurückgibt (z.B. im Zend-Framework). Dann benötigt man automatisch eine weitere Variable wie beispielsweise $xyz = $abc->getPost(‘xyz’), wodurch eine Warnung verhindert wird. Die Idealversion ohne Framework sieht für Strings daher für mich so aus:

//somewhere on top
$mystring = isset($_POST['mystring'])
            ? $_POST['mystring'] : '';
...
//somewhere else
if('' != $mystring) {
  /* some code */
}

Die korrekte Initialisierung von Variablen gehört irgendwo an den Anfang und sollte nicht durch einen isset()-Aufruf in jeder if-Abfrage erneut geprüft werden.

XOR

Das “Entweder oder” benutzt man doch häufiger als man denkt. Oft sieht es so im Code aus:

$input = 'einstring';

if (
  ( strpos($input, 'ein') !== false &&
    strpos($input, 'string') === false
  )
  ||
  ( strpos($input, 'string') !== false &&
    strpos($input, 'ein') === false
  ) ) {
  /* some code here*/
}

Das man die Stringprüfung ggfs. anders lösen kann, sei hier mal dahingestellt. Wichtig ist mir eigentlich nur, dass durch die Verwendung des XOR-Operators alles viel einfacher aussieht und man diese Lösungsmöglichkeit oft vergisst:

if( strpos($input, 'ein') !== false XOR
    strpos($input, 'string') !== false {

  /* some code */
}

Fazit

Vergleiche können so einfach sein Es gibt jedoch einige Fallstricke wie die angesprochenen ’0′-Werte in Strings, die man nicht außer Acht lassen sollte. Der === ist manchmal sogar kontraproduktiv. Zudem ist schöner Code oft unkompliziert! – PHP bietet hierfür viele Implementierungsvarianten.

Links

http://de.wikipedia.org/wiki/%C3%84quivalenzrelation

http://de.php.net/isset

http://de.php.net/__isset

http://de.php.net/empty

PHP ist hier leider etwas mager bestückt. Oft helfen sich Programmierer daher mit flock() und generieren ein exklusives Lock per Datei. Das funktioniert oft auch ganz gut. Flock garantiert allerdings keineswegs, das es das Locking auch sicher durchführen kann. Wer sich allein die Warnings in den Notes ansieht (siehe http://de.php.net/manual/en/function.flock.php), stellt schnell fest, dass es hier einige Fallstricke gibt. Man ist vor allem abhängig vom Dateisystem. Hat man beispielsweise mehrere Webserver, die ein NFS-Share nutzen, wird es komplizierter. Exklusive Locks funktionieren auf NFS-Shares nicht. Es gibt zwar speziell für NFS einen Workaround mit statischen Links. Eine wirkliche Unabhängigkeit vom Dateisystem hat man damit aber nicht geschaffen.

APC

Ein Locking mit dem APC-Cache ist grundsätzlich möglich. Folgendes, rundimentäres Beispiel zeigt, wie es aussehen könnte:

<?php
  define('MYLOCK', 'mylock');

  echo 'acquire lock...';
  ob_flush();
  flush();
  $i = 0;
  while(false === apc_add(MYLOCK, 1)) {
    usleep(100);
  }

  echo "done\n";
  ob_flush();
  flush();
  sleep(5); //something else can be done here
  echo 'release lock...';
  apc_delete(MYLOCK);
  echo "done\n";

Über den Webserver ausgeliefert, funktioniert das auch soweit. Man kann das Skript mehrmals starten und dann kann man verfolgen, ab wann das Lock vergeben wird. Dabei darf man nicht vergessen, dass die meisten Browser den Output puffern. Am einfachsten testet man es daher mit telnet:

telnet servername 80
Trying 1.2.3.4...
Connected to servername.
Escape character is '^]'.
GET /test.php
acquire lock...done
release lock...done
Connection closed by foreign host.

ob_flush() und flush() sorgen dabei noch zusätzlich dafür, dass der Output nicht auf der Server-Seite gepuffert wird. Geht das auch auf der Kommandozeile? – Nein! Zwar kann man hier mit dem Setting “apc.enable_cli = 1″ für die PHPCLI-Ini APC einschalten. Das Lock wird dann jedoch nicht funktionieren. Anders als bei Apache, läuft jedes Kommandozeilenskript für sich und ohne gemeinsam verwendeten Speicher ab. Das trifft auch für APC zu. Deshalb ist diese Methode für Konsolenskripte ungeeignet. Außerdem funktioniert sie auch nicht, wenn man mehrere Webserver im Einsatz hat. Denn jede Apache-Instanz hat ihren eigenen APC.

Semaphore

Auch wenn die Funktionen etwas rar gesäht sind, hält PHP jedoch auch das ein oder andere (fast) von Haus aus mitgebrachte Feature bereit (Modulinstallation ist wieder nötig). Semaphore sind beispielsweise eine aus der Betriebssystemwelt stammende Begrifflichkeit. Diese gibt es auch in PHP: http://de.php.net/manual/en/book.sem.php. Ein simples Beispiel:

<?php

  define('MYSEMAPHORE', 1);

  $semaphore = sem_get(MYSEMAPHORE);
  echo 'sem_acquire...';
  sem_acquire($semaphore);
  echo "done\n";
  sleep(5); //something else can be done here
  echo 'sem_release...';
  sem_release($semaphore);
  echo "done\n";

Die “flushes” habe ich mir hier gespart. Leider lösen Semaphore auch nicht das Problem, wenn man mehrere Webserver im Einsatz hat.

Memcache

Die letzte und mir am sinnvollsten erscheinende Lösung ist die Memcache-Lösung. Sie funktioniert genau wie der APC-Ansatz, nur mit dem Unterschied, dass der Memcache-Server auch über die Konsole und mehrere Webserver hinweg funktioniert. Dabei muss man sich klar machen: Memcached ist single-threaded. D.h. erfolgt ein Hinzufügen eines Keys, kann das nicht parallel stattfinden. Die Anfragen werden sozusagen serialisiert. Dies kann man sich für ein Lock zu Nutze machen:

<?php

  define('MYLOCK', 'mylock');

  echo 'acquire lock...';
  $memcache = memcache_connect("localhost", 11211);
  while(false === $memcache->add(MYLOCK, 1)) {
    usleep(100);
  }
  echo "done\n";
  sleep(5); //something else can be done here
  echo 'release lock...';
  $memcache->delete(MYLOCK);
  echo "done\n";

Genau wie bei dem APC-Vorschlag muss man sich auch hier Gedanken über mögliche Endlosschleifen und Deadlocks machen. Erstere könnte man mit einem Timeout in der While-Schleife, oder auch einfach mit einer Max-Life-Time des jeweiligen Keys verhindern. Dabei muss man die maximale Laufzeit des Skripts zwischen dem Akquirieren und dem Freigeben des Locks berücksichtigen – sonst hat man genau die gleichen Probleme wie ohne Locks. Zudem können beispielsweise Verbindungsprobleme zum Memcache-Server auftreten. Dann kann das Hinzufügen eines Keys länger dauern als erwartet und somit die Ausführungsdauer steigern. Mit vernünftigen Max-Lifetimes hat man aber ein gutes Steuerungsinstrument in der Hand. Benötigt ein einfaches DB-Update beispielsweise mehr als 5 Minuten, hat man eh ganz andere Probleme.

Weiterhin kann man sich überlegen, die Werte der Keys mit etwas sinnvollem zu füllen: Welcher/Welches Webserver/Prozess/Skript hat das Log geschrieben? Darf es nur derjenige Prozess freigeben, der es auch erstellt hat? Es gibt sicherlich noch viele Optimierungsmöglichkeiten bei der Memcache-Version… Ideen als Kommentar sind daher sehr willkommen.

Zend-Framework

Auch im Zend-Framework kann man das Memcache-Lock nutzen. Allerdings ist der Einbau nicht ganz trivial. Denn Zend_Cache_Backend_Memcached benutzt leider statt der add()-  die save()-Methode. Das hat zur Folge, dass kein Fehler auftritt, wenn der zu speichernde Key bereits vorhanden ist – das ist unbrauchbar für Locks.

Abhilfe schafft nur das Hinzufügen einer add()-Methode in einer von Zend_Cache_Backend_Memcached abgeleiteten Klasse. Je nachdem, wo man sein Backend initialisiert muss die Factory-Methode von Zend_Cache dann neue Parameter erhalten (nachfolgend der Prototyp der factory-Methode):

factory(
  mixed $frontend,
  mixed $backend,
  array $frontendOptions = array,
  array $backendOptions = array,
  boolean $customFrontendNaming = false,
  boolean $customBackendNaming = false,
  boolean $autoload = false
)

$backend muss dann auf den neuen Backendnamen verweisen und $customBackendNaming muss auf true gesetzt werden. Damit nicht genug. Auch das Frontend will angepasst werden – denn hier existiert die neue add()-Methode auch nicht. Die Anpassung kann aber analog zum Backend erfolgen. Wer sich die Tortur angetan hat, kann sich immerhin über exklusive Locks per Memcached freuen, die Zend-Framework-kompatibel sind

Fazit:

Auch in PHP können exklusive, verlässliche Locks mit ein wenig Handarbeit nachgerüstet werden. Ein wenig Gehirnschmalz muss man in die Implementierung aber stecken, um für Deadlocks und Co. gewappnet zu sein. Ich würde mir wünschen, dass solch grundlegende Funktionen zumindest ins Zend-Framework einzug halten und man keine komplizierten Implementierungen dafür benötigt.