(fourni par )

Améliorations
Un des problèmes principaux de l'extension shm que j'ai présenté au listing 2 est que toutes les opérations sont traitées sur un pied d'égalité : le système verrouille le sémaphore pour n'autoriser qu'une seule opération à un moment donné, sans faire de distinction entre les lectures et les écritures.

La vérité est que nous pourrions autoriser plusieurs processus à lire la mémoire simultanément, car ces opérations ne sont pas exclusives. Ce n'est que lorsque la mémoire doit être écrite que nous devons bloquer l'accès aux autres processus.

Notez que la nature des lectures est telle qu'elles sont très rapides, puisqu'il suffit d'extraire les données dans un segment de mémoire vive. Par conséquent, il n'y a pas besoin de méthode de synchronisation.

Cependant, si vous voulez en ajouter une, il faut être très prudent pour ne pas donner la priorité aux lectures sur les écritures : c'est une erreur courante et très coûteuse. Prenons un exemple. Considérez le mécanisme de stockage suivant :

concurrency = 0
semaphore read_sem
semaphore write_sem

read:

do true
  acquire (read_sem)
  concurrency++
  if (concurrency = 1)
    acquire (write_sem)
  fi
  release (read_sem)

  [Lecture de la mémoire ici]

  acquire (read_sem)
  concurrency
  if (concurrency = 0)
    release (write_sem)
  fi
od

write:

do true
  acquire (sem_write)

  [Ecriture de la mémoire ici]

  release (sem_write)
od

C'est une solution classique où le problème des écritures et des lectures causera un problème majeur en environnement Web. Le cœur de l'algorithme est le sémaphore "write" qui ne peut être posé que lorsqu'il n'existe aucune opération d'écriture en attente. D'un autre côté, les opérations de lecture simultanées peuvent être menées sans poser de verrou, avec un net gain d'efficacité. En théorie, vous aurez aussi besoin d'un autre sémaphore et d'un stockage global où la variable $concurrency sera stocké, et dans notre cas, cela annule tous les autres avantages.

Forum

Réagissez dans les forums de JDN Développeurs

Le vrai problème ici est que cet algorithme favorise les lectures par rapport aux écritures. Tant qu'il y a une lecture en cours, une autre lecture peut survenir et passer en priorité sur une écriture. Dans un environnement Web, notamment si le trafic est très fort, les opérations de lectures sont très fréquentes, et elles vont retarder les écritures. Il suffit que deux lectures se chevauchent suffisamment souvent pour que les écritures soient carrément interdites.