Pour reproduire les scénarios de concurrence et d’initialisation unique, j’ai utilisé :

• GnuCOBOL version 3.4 (ou supérieure) sur Debian 12 ou compatible Linux.\
• Un compilateur COBOL capable de gérer des appels C/C++ pour les primitives d’accès mémoire atomiques, si nécessaire au niveau du test bancaire simulé.
• Connaissance des mécanismes de synchronisation : locks (pessimistic) et flags atomiques.

Pour le contexte Mainframe z/OS 2.5, la compréhension des routines SET/GET ou l’utilisation d’un mécanisme de verrouillage au niveau du système d’exploitation est supposée.

Le pattern initialisation unique vise à garantir que la fonction complexe qui configure un ensemble de ressources coûteuses (connexions, caches internes, calculs lourds) ne soit exécutée qu’une seule fois durant le cycle de vie du programme. En programmation concurrente, cela est crucial pour éviter les race conditions.

En COBOL classique, la gestion des threads et de l’état partagé était souvent laborieuse ou dépendait fortement du produit (CICS Transaction Server vs Batch Job). Aujourd’hui, même avec GnuCOBOL 3.4+, quand on simule un environnement multi-threadé, le risque persiste.

Le modèle idéal est celui de la ‘Double Vérification et Verrouillage’ :

// Étape 1: Première vérification rapide (optimisation)
IF (RESOURCE_IS_INITIALIZED = FALSE) THEN DO
    // Étape 2: Acquisition du verrouillage critique
    ACQUIRE_LOCK(resource_lock); // Bloque tous les autres threads concurrents ici.

    TRY DO
        // Nouvelle vérification : Est-ce que quelqu'un d'autre a initialisé pendant mon attente de lock ?
        IF (RESOURCE_IS_INITIALIZED = FALSE) THEN
            CALL INITIALISER_RESOUCE(); // Bloc critique exécuté UNIQUEMENT ICI.
            SET RESOURCE_IS_INITIALIZED = TRUE;
    END TRY
    FINALLY DO
        RELEASE_LOCK(resource_lock); // Libération du verrouillage.
    END FINALLY DO
END IF

Le piège, c’est de ne pas penser au bloc ACQUIRE/RELEASE_LOCK. Si le code entre la première vérification et l’acquisition du lock est trop long, on peut perdre des performances (deadlock potentiel). Mais si ce bloc n’utilise pas de verrouillage explicite comme je l’ai fait ici, nous revenons à notre problème initial. Le initialisation unique ne se résume jamais d’un simple IF.

Le premier snippet (MAINLIB) illustre l’anti-pattern classique : la dépendance à une condition non atomique. La ligne IF WS-INITIALIZED-FLAG = 'N'. est le point faible. Le processeur peut interrompre les opérations entre la lecture de cette variable et son écriture, permettant ainsi aux deux threads d’entrer dans l’initialisation unique simultanément.

Le second snippet (MAINLIB-CORRECTED) introduit le concept du verrouillage explicite. La fonction ACQUIRE-LOCK est ici une abstraction de ce que ferait un vrai système d’exploitation ou l’API COBOL pour les ressources partagées (par exemple, utiliser des transactions DB2 avec COMMIT/ROLLBACK spécifiques). Elle force tous les autres threads à attendre dans la file d’attente jusqu’à ce qu’un seul puisse passer.

Le bloc critique est maintenant encapsulé entre ACQUIRE-LOCK et RELEASE-LOCK. Même si plusieurs threads attendent, un seul exécute le code qui appelle CALL CALCULER_CONSTANTE. C’est cette séquence atomique (verrouillage -> vérification -> action) qui garantit l’initialisation unique de la ressource globale.

Le piège à éviter, c’est d’oublier RELEASE-LOCK dans un bloc FINALLY (ou son équivalent COBOL/TRY-CATCH). Si le verrouillage n’est pas relâché même en cas d’erreur (CALL CALCULER_CONSTANTE plante), tous les autres threads seront bloqués pour toujours, menant à un deadlock système. Ce détail est crucial sur z/OS où la gestion des ressources mémoire et I/O doit être impeccable.

Imagine que je dois appeler cette routine dans mon programme principal, qui est appelé par 10 threads simultanément (simulés par un loop en GnuCOBOL).

*** Thread 1 tente l'initialisation... ***
--- Lock acquis. Entrée dans la zone critique. ---
!!! Début du processus d'initialisation unique... !!!
[CALCUL] Constante calculée : 12345678.
+++ Initialisation terminée. Constante calculée : 12345678.
--- Lock relâché. Exécution de Thread 1 terminée. ---
*** Thread 2 tente l'initialisation... ***
--- Lock acquis. Entrée dans la zone critique. ---
(Le code interne vérifie le flag et voit 'Y', il ne fait rien).
+++ Initialisation terminée. Constante calculée : 12345678.
--- Lock relâché. Exécution de Thread 2 terminée. ---

Statut final : Initialisation sécurisée. Constante: 12345678.

Ce résultat montre que, même avec des appels très rapprochés (simulant la contention), le bloc coûteux n’a été exécuté qu’une seule fois pour l’initialisation unique de la constante et du pool. C’est la preuve concrète que le verrouillage fonctionne.

L’application du pattern d’initialisation unique ne se limite pas aux constantes mathématiques. Elle s’étend à tout ce qui est coûteux et partagé en mémoire.

• Pool de connexions DB2/IMS : Au lieu d’ouvrir une nouvelle connexion pour chaque appel, on utilise l’initialisation unique du pool. Le bloc critique initialise le nombre maximal de connections et les maintient ouvertes. Contrainte : la gestion des timeouts réseau doit être intégrée dans ce setup initial.\
• Initialiseur de Traçage (Logging/Tracing) : Si l’application utilise un mécanisme avancé d’observabilité (ex: envoi à Kafka ou Splunk), le client qui gère la connexion au message broker ne doit jamais se réinitialiser. Le bloc critique garantit que seule une instance unique du Producer Client est créée et connectée, avec des mécanismes de re-connexion intégrés. Contrainte : faible latence d’accès aux logs en production.\
• Chargement de Modèles ML/AI Partagés : Si le COBOL interagit via un *exit* C++ pour charger des modèles complexes (ex: scoring de risque), ce modèle doit être chargé une seule fois dans la mémoire partagée. Le initialisation unique est obligatoire ici, car chaque tentative pourrait corrompre les poids du modèle ou dépasser la taille allouée en segment.
Cache de Configuration Réseau : Les paramètres réseau (endpoints externes, clés API) sont souvent lus à partir d’un fichier distant. Pour garantir l’initialisation unique et éviter les courses entre threads qui pourraient lire des versions incohérentes du config file pendant le déploiement, il faut verrouiller non seulement la lecture mais potentiellement la ressource elle-même (ex: un lock sur l’objet de configuration). Contrainte : gestion des échecs réseau lors de ce setup critique.

• Privilégier les verrous système : Ne pas se fier à des flags mémoire seuls. Utiliser toujours un verrouillage explicite (type SET/GET ou équivalent transactionnel) pour tout bloc d’initialisation unique.\
• Minimiser le temps dans la section critique : Le code qui doit être protégé par le lock ne doit contenir que le strict minimum nécessaire (la lecture/écriture de l’état et l’appel d’init). Tout calcul long doit se faire en amont.
• Adopter un modèle FINALLY DO / TRY-CATCH : Garantir qu’un mécanisme de libération du verrouillage est exécuté quoi qu’il arrive (succès, erreur runtime, arrêt forcé). C’est non négociable.\
• Tester la contention à l’échelle : Ne pas se contenter d’une exécution séquentielle. Il faut simuler des charges élevées (N=100 threads) pour valider que le mécanisme d’initialisation unique fonctionne sous pression.\
• Séparer l’état de la ressource : Le flag WS-INITIALIZED-FLAG ne doit pas être une simple variable, mais un enregistrement protégé dans le système pour garantir son atomicité.

Le pattern d’initialisation unique n’est pas qu’une question de syntaxe. C’est une garantie architecturale contre la complexité et l’éphémère nature du contexte multi-threadé ou job batch concurrentel. Ma recommandation est toujours : si tu dois initialiser quelque chose, considère immédiatement le pire scénario où deux processus arrivent en même temps.

Pour aller plus loin dans la compréhension des mécanismes de synchronisation avancés et l’évolution des normes COBOL, je te recommande vivement de consulter documentation COBOL.