Stockage statique, RPG et Threads

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.