> Tech > Stockage statique

Stockage statique

Tech - Par iTPro - Publié le 08 juin 2011
email


Quand vous appelez un programme ou un programme de services pour la première fois, le système alloue du stockage pour les variables de programmes globales et pour d'éventuelles variables dans les sous procédures définies par le mot-clé STATIC. Ce stockage est alloué au programme pour la durée

de vie du groupe d'activation. Chaque fois que vous appelez le programme, il utilise le même stockage pour ces variables. C’est alors un stockage statique.

Les deux autres types de stockage sont le stockage automatique et le stockage empilé. Le premier est utilisé pour la plupart des variables locales dans vos sous-procédures ; il est alloué à la procédure quand elle est appelée et désalloué quand elle revient. Le stockage empilé est alloué par %alloc et %realloc et désalloué par l’opcode DEALLOC.

Tous les modules RPG utilisent le stockage statique, même si le module n'a pas de variables globales, et si toutes les sous-procédures ne définissent que le stockage automatique. Le compilateur RPG utilise le stockage statique pour beaucoup de ses variables internes.

Si un job à deux threads actifs dans le même module, les deux peuvent accéder au stockage statique dans le module. C'est une situation potentiellement dangereuse. Soit le fragment de code suivant :

for index = 1 to 3;
arr(index) = arr(index) + 1;
endfor;

Si ces variables sont en stockage statique, et si un seul thread est actif dans le code, les variables progresseront dans la séquence des valeurs de la figure 1 en suivant le flux des instructions (les variables changeantes sont en rouge). À noter qu'une seul variable change à la fois. Si ces variables sont en stockage statique, et si deux threads à la fois sont autorisés à exécuter ce code, les variables pourraient progresser dans une séquence des valeurs.

Le problème n'est pas limité à deux threads exécutant le même code. Un thread peut fort bien exécuter le fragment de code ci-dessus, tandis qu'un autre exécute le code qui a initialisé la matrice en lisant les enregistrements d'un fichier. Vous ne pouvez pas autoriser ce genre d'interaction dans une application thread-safe. Ces variables statiques sont une ressource partagée, dont l'accès par plusieurs threads doit être surveillé de près.

RPG contrôle de deux manières l'accès au stockage statique d'un module. Quand vous spécifiez THREAD(*SERIALIZE), il est impossible pour deux threads d'exécuter le même code en même temps. En fait, il est impossible pour deux threads de s'exécuter dans une procédure du module en même temps. Si le thread T1 est en train d'exécuter la procédure PROC1, et si le thread T2 tente d'appeler la procédure PROC2 dans le même module, le thread T2 ne pourra commencer l'exécution de PROC2 que quand le thread T1 sera revenu et ne sera plus actif dans le module.

Quand vous spécifiez THREAD(*CONCURRENT), chaque thread a sa propre copie du stockage statique du module. Si le thread T2 commence la boucle et met l'index à 1, l'index que le thread T1 utilise, n'est pas affecté. Avec THREAD(*CONCURRENT), le stockage statique n'est pas une ressource partagée, et donc il n'est pas concerné par la sécurité des threads.

Téléchargez gratuitement cette ressource

Protection des Données : 10 Best Practices

Protection des Données : 10 Best Practices

Le TOP 10 des meilleures pratiques, processus et solutions de sécurité pour mettre en œuvre une protection efficace des données et limiter au maximum les répercutions d’une violation de données.

Tech - Par iTPro - Publié le 08 juin 2011