A propos des sémaphores

Dans un programme informatique, un sémaphore est un outil permettant de protéger des actions qui ne doivent être réalisées que par un seul process ou utilisateur à la fois.

Dans 4D, le besoin classique d'usage d'un sémaphore est la modification d'un tableau interprocess : si un process est en train de modifier les valeurs du tableau, il ne faut pas qu'un autre process puisse faire la même chose en même temps. Le développeur utilise un sémaphore pour indiquer à un process qu'il ne peut réaliser la suite des opérations que si aucun autre process n'est déjà en train de réaliser les mêmes tâches. Lorsqu'un process rencontre un sémaphore, il y a trois possibilités :

• il obtient immédiatement le droit de passer
• il attend son tour, et cela jusqu'à ce qu'il obtienne le droit de passer
• il passe son chemin en abandonnant l'idée de réaliser les tâches.

Le sémaphore permet donc de protéger des parties de code. Le sémaphore ne laisse passer qu'un process à la fois et interdit l'accès tant que le process détenteur du droit d'usage ne redonne pas son droit en libérant le sémaphore.

Dans 4D, vous posez un sémaphore en appelant la fonction Semaphore. Pour libérer un sémaphore, vous appelez la commande EFFACER SEMAPHORE.

La fonction Semaphore a un comportement très particulier car elle réalise potentiellement deux actions en même temps :

• si le sémaphore est déjà attribué, la fonction retourne Vrai
• si le sémaphore n'est pas attribué, la fonction attribue le sémaphore au process et répond Faux dans le même temps.

Ce principe de double action effectuée par la même commande permet de garantir qu'aucune opération extérieure ne peut s'insérer entre le test du sémaphore et son attribution.

La commande Tester semaphore permet de savoir si un sémaphore est déjà attribué ou non. Cette commande est principalement utile dans le cadre d'opérations longues, comme par exemple la clôture annuelle de la comptabilité, où Tester semaphore permet de contrôler l'interface pour interdire l'accès à certaines opérations telles que l'ajout de données comptables.

Il est recommandé d'utiliser les sémaphores en respectant les principes suivants :

• un sémaphore doit être posé et libéré dans la même méthode,
• l'exécution du code protégé par le sémaphore doit être la plus courte possible,
• le code doit être temporisé à l'aide du paramètre nbTicks de la fonction Semaphore pour attendre la libération du sémaphore.

Voici le code type d'utilisation d'un sémaphore :

Un sémaphore non libéré peut provoquer le blocage d'une partie de la base. Poser et libérer le sémaphore au sein de la même méthode permet pratiquement d'éliminer ce risque.

Réduire au maximum le code protégé par le sémaphore augmente la fluidité de l'application et évite que le sémaphore soit un goulot d'étranglement. 

Enfin, l'utilisation du paramètre optionnel nbTicks de la commande Semaphore est indispensable pour optimiser l'attente de la libération d'un sémaphore. Avec ce paramètre, la commande fonctionne de la manière suivante :

• le process attendra au maximum ce nombre de ticks (300 dans l'exemple) que le sémaphore soit disponible, sans que l'exécution du code passe à la ligne suivante,
• si le sémaphore est libéré avant la fin du délai imparti, il est immédiatement attribué au process (Semaphore retourne Faux) et l'exécution du code reprend
• si le sémaphore n'est pas libéré avant la fin du délai imparti, l'exécution du code reprend.

La commande réalise également une priorisation des demandes en mettant en place une file d'attente. Ainsi, le premier process demandant un sémaphore sera le premier à l'obtenir.

A noter que la durée d'attente est à régler en fonction des spécificités de l'application.

Il y a deux types de sémaphores dans 4D : les sémaphores locaux et les sémaphores globaux.

• Un sémaphore local est visible par tous les process d'un même poste et seulement sur ce poste. Vous déclarez un sémaphore local en préfixant son nom avec le signe dollar ($). Les sémaphores locaux permettent de contrôler des opérations entre les différents process exécutés sur le même poste. Par exemple, un sémaphore local peut être utilisé pour gérer les accès à un tableau interprocess appelé par tous les process d'une base de données mono-utilisateur ou d'un poste client.

• Un sémaphore global est visible par tous les utilisateurs et tous les process. Les sémaphores globaux permettent de contrôler des opérations entre les postes clients d'une base multi-utilisateurs.

Le principe de fonctionnement des sémaphores globaux et locaux est identique. Leur différence réside uniquement dans leur portée, c'est-à-dire leur visibilité. En client-serveur, les sémaphores globaux sont visibles pour tous les process de tous les postes clients et du serveur. Un sémaphore local n'est visible que pour les process du poste sur lequel il a été créé.

Avec 4D, les sémaphores globaux et locaux ont la même portée car il n'y a qu'un seul utilisateur. Cependant, si votre base est utilisée dans les deux environnements, n'hésitez pas à employer des sémaphores globaux et locaux, en fonction de vos besoins.

Note : Les sémaphores locaux sont recommandés lorsque l'usage d'un sémaphore est nécessaire pour gérer un aspect local à un client de l'application, comme par exemple l'interface ou un tableau de valeurs interprocess. L'utilisation d'un sémaphore global provoquerait dans ce cas non seulement des échanges réseau inutiles, mais en plus pourrait affecter inutilement d'autres postes clients. Le sémaphore local évitera ces effets indésirables.