Depuis le manuel PHP de l' extension pthreads :
pthreads est une API orientée objet qui permet le multi-threading utilisateur en PHP. Il comprend tous les outils dont vous avez besoin pour créer des applications multithreads ciblées sur le Web ou la console. Les applications PHP peuvent créer, lire, écrire, exécuter et se synchroniser avec des threads, des ouvriers et des empilables.
Aussi incroyable que cela puisse paraître, c'est tout à fait vrai. Aujourd'hui, PHP peut multi-thread pour ceux qui souhaitent l'essayer.
La première version de PHP4, le 22 mai 2000, PHP a été livrée avec une architecture thread-safe - un moyen d'exécuter plusieurs instances de son interpréteur dans des threads séparés dans des environnements SAPI (Server API) multi-threads. Au cours des 13 dernières années, la conception de cette architecture a été maintenue et avancée: depuis lors, elle est utilisée en production sur les plus grands sites Web du monde.
Threading dans le domaine des utilisateurs n'a jamais été une préoccupation pour l'équipe PHP, et il le reste aujourd'hui. Vous devez comprendre que dans le monde où PHP fait ses affaires, il existe déjà une méthode définie de mise à l'échelle - ajouter du matériel. Au fil des années, PHP a existé, le matériel est devenu moins cher et moins cher, ce qui est devenu de moins en moins une préoccupation pour l'équipe PHP. Alors qu'il devenait moins cher, il est également devenu beaucoup plus puissant; aujourd'hui, nos téléphones mobiles et tablettes ont des architectures double et quad core et beaucoup de RAM pour l'accompagner, nos ordinateurs de bureau et serveurs ont généralement 8 ou 16 cœurs, 16 et 32 gigaoctets de RAM, bien que nous ne puissions pas toujours en avoir deux dans le budget et avoir deux ordinateurs de bureau est rarement utile pour la plupart d'entre nous.
De plus, PHP a été écrit pour le non-programmeur, c'est la langue maternelle de nombreux amateurs. La raison pour laquelle PHP est si facilement adopté est qu'il s'agit d'un langage facile à apprendre et à écrire. La raison pour laquelle PHP est si fiable aujourd'hui est à cause de la grande quantité de travail qui va dans sa conception, et de chaque décision prise par le groupe PHP. C'est sa fiabilité et sa grandeur qui le maintiennent sous les projecteurs, après toutes ces années; où ses rivaux sont tombés sous la pression du temps ou de la pression.
La programmation multi-thread n'est pas facile pour la plupart, même avec l'API la plus cohérente et la plus fiable, il y a différentes choses à penser et de nombreuses idées fausses. Le groupe PHP ne souhaite pas que le multi-threading des utilisateurs soit une fonctionnalité essentielle, il n'a jamais reçu une attention particulière - et à juste titre. PHP ne doit pas être complexe, pour tout le monde.
Tout bien considéré, il y a encore des avantages à avoir à permettre à PHP d'utiliser ses fonctionnalités prêtes pour la production et testées pour permettre de tirer le meilleur parti de ce que nous avons, lorsque l'ajout de plus n'est pas toujours une option, et pour beaucoup des tâches n'est jamais vraiment nécessaire.
pthreads réalise, pour ceux qui souhaitent l'explorer, une API qui permet à un utilisateur de multi-thread des applications PHP. Son API est un travail en cours et a désigné un niveau bêta de stabilité et d'exhaustivité.
Il est de notoriété publique que certaines des bibliothèques utilisées par PHP ne sont pas sûres pour les threads, il devrait être clair pour le programmeur que pthreads ne peut pas changer cela et n'essaye pas d'essayer. Cependant, toute bibliothèque thread-safe est utilisable, comme dans toute autre configuration thread-safe de l'interpréteur.
pthreads utilise des threads Posix (même sous Windows), ce que le programmeur crée sont de vrais threads d'exécution, mais pour que ces threads soient utiles, ils doivent être conscients de PHP - capable d'exécuter du code utilisateur, de partager des variables et de permettre un moyen de communication utile (synchronisation). Ainsi, chaque thread est créé avec une instance de l'interpréteur, mais de par sa conception, son interpréteur est isolé de toutes les autres instances de l'interpréteur - tout comme les environnements d'API serveur multi-thread. pthreads tente de combler le fossé d'une manière saine et sûre. Beaucoup des préoccupations du programmeur de threads en C ne sont tout simplement pas là pour le programmeur de pthreads, de par leur conception, pthreads est copie en lecture et copie en écriture (la RAM est bon marché), donc aucune instance ne manipule jamais les mêmes données physiques , mais ils peuvent tous deux affecter les données d'un autre thread.
Pourquoi copier en lecture et copier en écriture:
public function run() {
...
(1) $this->data = $data;
...
(2) $this->other = someOperation($this->data);
...
}
(3) echo preg_match($pattern, $replace, $thread->data);
(1) Lorsqu'un verrou de lecture et d'écriture est maintenu sur le magasin de données d'objets pthreads, les données sont copiées de leur emplacement d'origine en mémoire vers le magasin d'objets. pthreads n'ajuste pas le refcount de la variable, Zend est capable de libérer les données d'origine s'il n'y a pas d'autres références à celles-ci.
(2) L'argument de someOperation fait référence au magasin d'objets, les données d'origine stockées, dont elle-même une copie du résultat de (1), sont copiées à nouveau pour le moteur dans un conteneur zval, tandis que cela se produit un verrou de lecture est maintenu sur le magasin d'objets, le verrou est libéré et le moteur peut exécuter la fonction. Lorsque le zval est créé, il a un refcount de 0, ce qui permet au moteur de libérer la copie à la fin de l'opération, car aucune autre référence n'existe.
(3) Le dernier argument de preg_match fait référence au magasin de données, un verrou de lecture est obtenu, l'ensemble de données de (1) est copié dans un zval, toujours avec un refcount de 0. Le verrou est libéré, l'appel à preg_match fonctionne sur une copie des données, qui est elle-même une copie des données originales.
Choses à savoir:
La table de hachage du magasin d'objets où les données sont stockées, thread-safe, est
basée sur la TsHashTable livrée avec PHP, par Zend.
Le magasin d'objets a un verrou de lecture et d'écriture, un verrou d'accès supplémentaire est fourni pour la TsHashTable de sorte que si cela nécessite (et c'est le cas, var_dump / print_r, un accès direct aux propriétés comme le moteur PHP veut les référencer) les pthreads peuvent manipuler la TsHashTable en dehors de l'API définie.
Les verrous ne sont maintenus que pendant les opérations de copie, lorsque les copies ont été faites, les verrous sont libérés, dans un ordre raisonnable.
Ça signifie:
Lorsqu'une écriture se produit, non seulement un verrou de lecture et d'écriture est maintenu, mais un verrou d'accès supplémentaire. La table elle-même est verrouillée, il n'y a aucun moyen possible qu'un autre contexte puisse la verrouiller, la lire, l'écrire ou l'affecter.
Lorsqu'une lecture se produit, non seulement le verrou de lecture est maintenu, mais également le verrou d'accès supplémentaire, la table est à nouveau verrouillée.
Deux contextes ne peuvent accéder physiquement ni simultanément aux mêmes données à partir du magasin d'objets, mais les écritures effectuées dans n'importe quel contexte avec une référence affecteront les données lues dans n'importe quel contexte avec une référence.
Il s'agit d'une architecture sans partage et la seule façon d'exister est de coexister. Ceux qui sont un peu avertis verront cela, il y a beaucoup de copies en cours ici, et ils se demanderont si c'est une bonne chose. Beaucoup de copies se font dans un environnement d'exécution dynamique, c'est la dynamique d'un langage dynamique. pthreads est implémenté au niveau de l'objet, car un bon contrôle peut être obtenu sur un objet, mais les méthodes - le code exécuté par le programmeur - ont un autre contexte, sans verrouillage ni copie - la portée de la méthode locale. La portée de l'objet dans le cas d'un objet pthreads doit être traitée comme un moyen de partager des données entre des contextes, c'est son but. Dans cet esprit, vous pouvez adopter des techniques pour éviter de verrouiller le magasin d'objets sauf si cela est nécessaire,
La plupart des bibliothèques et extensions disponibles pour PHP sont des wrappers légers autour de tiers, les fonctionnalités de base de PHP sont dans une certaine mesure la même chose. pthreads n'est pas une mince enveloppe autour de Posix Threads; c'est une API de threading basée sur Posix Threads. Il ne sert à rien d'implémenter des Threads en PHP que ses utilisateurs ne comprennent pas ou ne peuvent pas utiliser. Il n'y a aucune raison pour qu'une personne qui ne sait pas ce qu'est ou ce qu'est un mutex ne puisse pas profiter de tout ce qu'elle possède, à la fois en termes de compétences et de ressources. Un objet fonctionne comme un objet, mais partout où deux contextes se heurteraient autrement, pthreads offre stabilité et sécurité.
Quiconque a travaillé en java verra les similitudes entre un objet pthreads et le threading en java, ces mêmes personnes auront sans doute vu une erreur appelée ConcurrentModificationException - car cela sonne une erreur générée par le runtime java si deux threads écrivent les mêmes données physiques simultanément. Je comprends pourquoi cela existe, mais cela me déconcerte qu'avec des ressources aussi bon marché soient-elles, couplées au fait que le moteur d'exécution est capable de détecter la concurrence au moment exact et unique où la sécurité pourrait être assurée pour l'utilisateur, qu'il choisit de lancer une erreur potentiellement fatale lors de l'exécution plutôt que de gérer l'exécution et l'accès aux données.
Aucune erreur de ce genre ne sera émise par pthreads, l'API est écrite pour rendre le threading aussi stable et compatible que possible, je crois.
Le multi-threading n'est pas comme l'utilisation d'une nouvelle base de données, une attention particulière doit être portée à chaque mot du manuel et aux exemples livrés avec pthreads.
Enfin, à partir du manuel PHP:
pthreads était, et est, une expérience avec d'assez bons résultats. Chacune de ses limitations ou fonctionnalités peut changer à tout moment; c'est la nature de l'expérimentation. Ses limitations - souvent imposées par l'implémentation - existent pour une bonne raison; le but de pthreads est de fournir une solution utilisable au multitâche en PHP à tous les niveaux. Dans l'environnement dans lequel pthreads s'exécute, certaines restrictions et limitations sont nécessaires afin de fournir un environnement stable.
pcntl_fork()) fonctionnera s'il est appelé depuis Apache?