[R] Modèle de script pour exécution séquentielle/parallèle

[ZDS]

Bonjour à tous!

J'ai depuis un moment pas mal de souci à choisir un modèle de code, une sorte de template, qui permettrait à un script de choisir si son exécution doit être séquentielle ou parallèle à celui du script appelant; sachant que ce choix est à la discrétion du script fils appelé, et non du père...

Ça y est, certains ont décroché je comprends, c'est pas non plus des plus simples à expliquer ^^

1) Le besoin :

J'ai un script (qu'on appellera père) qui a une interface graphique avec tout plein de boutons, chacun permettant de lancer des scripts différents (qui s'appelleront fils). Les fils sont de deux types particuliers :
- séquentiels, c'est à dire que quand le père lance le fils, le père attend la fin de l'exécution du fils avant de reprendre son cours normal, à la manière d'un RunWait.
- parallèles, c'est à dire que le père lance le fils et continue son chemin sans se préoccuper du reste, comme avec un Run.
Ces modes parallèle et séquentiel sont définis par le fils, c'est le fils qui sait si le père doit attendre qu'il ait fini son boulot, le père n'en sait rien. Petites contraintes (mais pas des moindres), ce système doit fonctionner aussi bien avec des scripts (au3) qu'avec des exécutables (exe), et bien sûr ce choix doit s'abstraire de la machine ou autre.

2) Les idées envisagées :

a) Les sémaphores mutex :
Pour un tel système, le plus simple question architecture aurait été d'utiliser des mutex propres. Grâce à une exclusion mutuelle de sémaphores il est facile de faire un système de rendez vous de processus :
- Le père lance le fils en mode Run sans attente, puis instancie un double mutex pour un rendez vous (l'attente se fait à ce moment donc).
- Le fils se lance. En mode parallèle, il libère le double mutex de rendez-vous directement à son lancement. En mode séquentiel, il libère le double mutex de rendez-vous directement à son extinction.
Malheureusement je n'ai pas trouvé de véritables sémaphores configurables en AutoIt. Même en utilisant user32.dll je n'ai pas réussi a avoir une véritable prise de jeton avec des opérations P et V toutes bêtes.

b) Les propriétés étendues des fichiers :
En utilisant les propriétés étendues des résumés (clic droit sur un fichier > Propriétés > Résumé), il y aurait moyen d'y ajouter une info "Ce programme est en séquentiel" ou "en parallèle". Mais on se heurte à pas mal de souci en utilisant ça : Déjà, les propriétés étendues sur certains fichiers (dont les scripts) sont liés au système d'exploitation/au format du disque, et donc ne peuvent pas s'abstraire de la machine. On perd ce genre d'infos quand on passe sur une clef USB en FAT ou quand on le transfert via FTP ou mail (un peu comme un contact téléphonique avec numéro fixe portable pro adresse mail postale et anniversaire, quand on le copie vers sa carte SIM, le nom est tronqué à 16 caractères et on n'a plus que les numéros de téléphone ^^). Bref, il n'y a pas de constance et mise à part si les infos sont en dur (comme les infos AutoIt3Wrapper après compilation : auteur description version, mais donc on oublie pour les scripts) on ne peut pas en faire grand chose.

c) L'auto-redémarrage : Solution adoptée pour le moment
Il existe un mot magique dans ce système, la chaine de caractères "--LAUNCH" par exemple.
Le père lance tous les fils de la même façon, à la manière d'un RunWait classique sans argument particulier (ou avec certains arguments si besoin, mais pas le mot magique). Les fils séquentiels n'ont qu'à faire leur travail comme tout bon script, s'éteindre et redonner la main au père.
Les fils parallèles quant à eux, ne voyant pas dans $cmdLine le mot magique n'ont plus qu'à se relancer en l'ajoutant à la fin et s'éteindre tout de suite après. Le père reprend alors la main, et le clone du fils avec son "--LAUNCH" poursuit son travail de façon classique, les deux tournants alors en parallèle.

---

Voila un joli pavé, et merci à ceux qui l'ont lu (et compris) jusqu'au bout

Ma question est tout simplement la suivante : Est ce qu'il y a moyen de faire plus efficace, plus simple ou plus sécurisé?

A bientôt !

[zeshrek]

Pour ta solution 1, je te suggère de passer par des clés de registre pour tes sémaphores.
Tu crées une valeur dont chaque bit corresponda a une application
Le pere lance systématiquement les fils en run, puis positionne a 1 le bit correspondatn a cette appli dans la registry
Il se met ensuite dans une boucle tant que la valeur de la registry est <>0
Si le fils s'exécute en paralelle, le premier truc qu'il va faire consistera a remettre ce bit a zero (du coup le pere reprendra le cours de sa vie) sinon, si il est séquenciel, il le remetra a zero en quitant pour rendre la main au pere.
Tu peux même ne pas avoir un N° spécifique pour chaque appli, et juste le déterminer au moment du lancement, et le pere le passe en parametre au fils.

Pour ta solution 2 j'ai pas trop compris, donc je me pencherai modérément sur la question

Pour la solution 3, je vois une solution un peu dans le me^me style que la 1, mais 100% gérée par les fils :
1/ le pere lance systématiquement les script fils en RunWait (ou shellExecuteWait), cad il attend.
2/ Si le fils est effectivement séquenciel, bin il s'execute, puis rend la main
3/ Si le fils est parallele, en fait le fils lancera un petit-fils en Run (ou ShellExecute) puis se terminera, rendant la main au père. Du coup le petit fils s'éxécutera en parallele du pere.

C'est relativement simple a mettre en oeuvre, même si ca alourdit un chouilla la procédure en rajoutant moult fils dont le seul but est de lancer le petit fils...

[sksbir]

Bonjour

Voici ma contribution, mais c'est plutôt en complément de ce que tu veux faire: [Ex] Script réentrant.

Et pour cibler plus particulièrement ton besoin je pense que tu peux effectivement partir sur la base d'un script réentrant:

- la section "père" se lance quand on appelle le script sans arguments.
- LA sections "fils" se lance sur appel du père, avec des arguments biens ciblés du genre "FR" ou "FW" ( comme Fils/run ou fils/runwait). Du coup, la section fils, c'est du style

► Afficher le texteextrait de code

Code : Tout sélectionner

if $CMDELINE[0]>2 then
if $CMDELINE[1]="FR" then
run($CMDLINE[3])
elseif $CMDELINE[1]="FW" then
runwait($CMDLINE[3])
endif

[jchd]

As-tu regardé les posibilités de _Singleton() ?

Sinon, la variant du Shrek employant une clé est correcte.

[zeshrek]

Sinon, la variant du Shrek employant une clé est correcte.

Bon, forcément j'aurai préféré que tu juges ma proposition Excélente, parfaite, ou même pourquoi pas génialissime. Mais bon, correct, c'est déjà pas si mal
Je suis ému !

[ZDS]

Bonjour !

@Zeshrek:

Pour le système des clefs de la base de registre de Zeshrek (je vais me faire un ennemi), c'est malheureusement quelque chose que je considère comme une méthode pas propre, en opposition aux sémaphores de base qu'on voit au niveau noyau; la lecture/écriture n'agit pas comme une opération atomique, c'est là qu'un mutex serait utile ^^ Car derrière cette application toute simple de père fils, je compte appliquer le modèle à un système de travail en algorithmique distribuée... Et là, sur 99% des cas où tout se passerait bien, 1% des cas feront vautrer tout le truc à cause d'une opération ayant eu lieu entre la lecture et l'écriture.

Exemple avec P1 et P2 qui effectuent tous les deux une opération P sur un même sémaphore Sem(N>2, val=0), il peut arriver que P.val arrive à 1 au lieu de 2, si on utilise une clef de registre ou tout autre système basique.
1) P1 lance un P : deux étapes
1a) P1 lit Sem.val => x = 0
1b) P1 écrit x+1 dans Sem.val => Sem.val = 1
2) P2 lance un P : deux étapes aussi
2a) P1 lit Sem.val => y = 1
2b) P1 écrit y+1 dans Sem.val => Sem.val = 2

Maintenant imaginons que l'ordi et son tourniquet de processus par quantum s'amuse à effectuer les opérations dans un ordre bizarre (bah oui, ce sont deux processus parallèles) :
1) P1 lance un P
2) P2 lance un P
1a) P1 lit Sem.val => x = 0
2a) P2 lit Sem.val => y = 0
1b) P1 écrit x+1 dans Sem.val => Sem.val = 1
2b) P2 écrit y+1 dans Sem.val => Sem.val = 1

Et hop plantage du système à cause d'un accès concurrent... :s C'est pour cela qu'un véritable système de sémaphores en AutoIt aurait été le pied.

Pour la solution 3 que tu proposes, c'est comme je disais la solution que j'ai déjà adopté En fait voici mon "template" :

► Afficher le texteTemplate, entête d'un script fils

Code : Tout sélectionner

; Entête du module
Global Const _
    $MODULE_NOM = "Mon Module", $MODULE_AUTEUR = "ZDS", $MODULE_VERSION = "1.0", _
    $LAUNCH_PARAMETER = "-launch", $DEBUG_MODE = (FileExists("debug.txt")=1)
If StringLower($cmdLine[$cmdLine[0]]) <> $LAUNCH_PARAMETER Then ; Lancement parallèle
    Local $ligne = ""
    If $cmdLineRaw<>"" Then $ligne = $cmdLineRaw&" "
    If Not @Compiled Then
        Run(@AutoItExe&' "'&@ScriptFullPath&'" '&$ligne&$LAUNCH_PARAMETER, @ScriptDir)
    Else
        ShellExecute(@ScriptFullPath, $ligne&$LAUNCH_PARAMETER, @ScriptDir)
    EndIf
    Exit
ElseIf $DEBUG_MODE Then ; Notification du Debug Mode
    MsgBox(0, $MODULE_NOM&" v"&$MODULE_VERSION, "Debug mode activé", 1)
EndIf

; Véritable code du fils
; ...
; ...
; ...

@jchd

J'ai justement repris le code source de Singleton il y a un moment (dans Misc.au3 je crois, non?), mais même en bidouillant avec user32.dll, je n'ai jamais réussi à faire fonctionner des opérations P et V correctes (pas forcément des mutex, je voulais faire des sémaphores généraux). j'avais déjà posté une demande il y a presque un an à ce propos : http://autoitscript.fr/forum/viewtopic.php?f=3&t=5431

@sksbir

Pour ce principe, j'ai déjà mis en place un exemple qui gère les arguments (le père peux ainsi appeler les fils avec des arguments si besoin, et même forcer le mode séquentiel (qui peut le plus peut le moins). cf l'exemple un peu plus haut.

---

Apparemment ce qui en ressort, c'est que la solution 3 est adoptée un peu partout, mais est-ce la meilleure? et surtout, y aurait-il moyen de mettre de vrais sémaphores en place? Et aussi existe-t-il une UDF de véritables sémaphores généraux? ^^

Merci d'avance et à bientôt !

[jchd]

@ZDS,
Pour la synchro pa registre, je ne suis pas bien d'accord avec toi. Tu peux parfaitement utiliser le registre pour une synchro sans heurt. Crée une clef spécifique à chaque process fils et une énumération de valeurs qui représentent chacune un état dans le dialogue, par exemple :
0 = posé par le père, process fils inactif.
1 = posé par le père, signifie que le process fils est lancé et qu'il attend sa réponse
2 = posé par le fils, implique que le père doit attendre la valeur 3
3 = posé par le fils, process terminé donc le père peut reprendre la main (et remettre la valeur 0)
4 = posé par le fils, le père n'a pas à attendre (et peut continuer à guetter la fin du fils, pour info, via la valeur 5)
5 = posé par le fils, process terminé donc le père peut remettre la valeur 0
Autres états pour signification d'erreur ou autres besoins.

C'est un automate à états tout simple. Etant donné que chaque action est une "simple" écriture sans avoir besoin de lecture la précédant, il n'y a aucun risque de problème si tout ce petit monde respecte ce "protocole".

[zeshrek]

@Zeshrek:
Pour le système des clefs de la base de registre de Zeshrek (je vais me faire un ennemi), ...

Meuh non !
Tu risque quoi ? Un ban d'une petite semaine, un mois maxi, c'est tout

...c'est malheureusement quelque chose que je considère comme une méthode pas propre, en opposition aux sémaphores de base qu'on voit au niveau noyau; la lecture/écriture n'agit pas comme une opération atomique, c'est là qu'un mutex serait utile ^^ Car derrière cette application toute simple de père fils, je compte appliquer le modèle à un système de travail en algorithmique distribuée...

Et là, c'est le drame !
J'ai rien compris

Ceci dit...J'ai vu que tu parlais d'acces concurrents. Moi de ce j'ai compris, il y a 2 solutions
Le fils demande au pere de s'arreter, ou pas.
Donc si le pere s'arrete, il ne va rien faire d'autre et du coup il ne peut pas lancer un autre fils qui lui demanderait de continuer
Si le fils laisse le pere continuer et que celui ci lance un autre fils qui demande au pere de s'arreter, ca ne dérange pas le premier fils puisque celui ci a dit des son lancement au pere de continuer a travailler, du coup peu importe la suite.

Au final, avec ce susteme de flag, on peut avoir autant de fils paralelles qu'on veut, puisqu'ils donnent le go au pere dès leur lancement, et ensuite ils ne font plus d'acces au flag. Par contre on peut avoir un seul fils séquenciel, puisque lui ne dit au pere de redémarrer que lorsqu'il se termine lui même. là encore il n'y aura pas d'autre acces au flag puisqu'il sera le seul a y accéder.

A moins que me gourre-je ?

[sksbir]

...c'est malheureusement quelque chose que je considère comme une méthode pas propre, en opposition aux sémaphores de base qu'on voit au niveau noyau; la lecture/écriture n'agit pas comme une opération atomique, c'est là qu'un mutex serait utile ^^ Car derrière cette application toute simple de père fils, je compte appliquer le modèle à un système de travail en algorithmique distribuée...

Et là, c'est le drame !
J'ai rien compris

C'est des notions de programmation en temps réel : une opération atomique ne serait pas interruptible, ce qui n'est pas la cas d'une requête d'écriture sur un fichier ou dans une clé de registre ( si j'ai tout compris )

La solution consiste donc à gérer un drapeau en plus du reste qui te garanti l'écriture aux données. tu peux utiliser un algorithme similaire à celui utilisé pour la gestion d'un réseau Ethernet, quelque chose comme ça:

► Afficher le texte

Code : Tout sélectionner

$SUCCES_ACCES=0

while $SUCCES_ACCES=0


$DROIT_ECRITURE=1

while ($DROIT_ECRITURE<>0)
    sleep(random..) ; l'attente d'un délai ALEATOIRE est la clé du succès.
    lire $DROIT_ECRITURE
wend
regwrite(.... $DROIT_ECRITURE,valeur unique de ce script)
sleep(100)
$DROIT_ECRITURE = regread(..... ) ; on vérifie qu'on n'est bien celui qui a le droit d'écrire.

if $DROIT_ECRITURE= valeur unique de ce script then

; on a le droit d'écriture sur les valeurs communes.... on fait donc nos écriture

regwrite(.... $DROIT_ECRITURE,0) ; on libère le droit d'écrire...

$SUCCES_ACCES=1 ; on a réussi à écrire.
endif

wend

[ZDS]

C'est vrai que ce genre de machine a état se place très bien dans le cas du père et ses N fils, car le père (pour plus de sécurité) n'a qu'à créer la clef avant de créer le fils (mais dans ce cas là, vu qu'aucune donnée ne transite entre les deux par la suite, autant le laisser en lecture). Au final, le père crée la clef, et lit la clef. Le fils lui ne fait qu'écrire sur la clef.
OK c'est fonctionnel pour ce système 1/N.

Par contre, je ne suis pas d'accord du tout pour un modèle entièrement parallèle et distribué où un fils peut devenir le père d'un ancien père (le processus étant mort, ce n'est pas un vrai père, mais un fils qui s'exécute avec le code du précédent père); et dans ce genre d'architecture distribuée, on ne peut pas gérer ces accès concurrents à une même clef de registre (que ce soit en lecture ou en ecriture), sans une certaine rigueur concernant l'unicité de certains opérations.

Une clef spécifique par fils n'est pas faisable, les différents processus n'ayant pas à savoir qui a déjà la main (ton système demanderait d'avoir la liste des processus ayant pris le jeton de telle ou telle ressource, les sémaphores n'ont qu'à dire si la ressource est prise). Une clef par ressource n'est pas faisable non plus, sinon ça serait un vrai bordel, la clef de registre étant elle même une ressource ça serait sans fin ^^ Enfin, j'ai essayé de comprendre ce que tu proposes, je ne pense pas avoir compris ce que tu voulais dire par là.

Voici un exemple de script qui montre bien ce qu'est un accès concurrent en AutoIt : Dans ce script, chaque script incrémente 1.000 fois une valeur de clef, dix processus sont lancés en parallèle, donc en partant de zéro, la valeur finale de la clef devrait être 10 x 1000 = 10.000, or, il y a environ 20% des opérations qui passent à la trappe (on est d'accord, c'est inadmissible tel quel) :

► Afficher le texteAccès concurrent

Code : Tout sélectionner

#RequireAdmin

; Entête du module
Global Const $LAUNCH_PARAMETER = "JE_SUIS_UN_FILS"
Global $NOM, $DATA[10]
If StringLower($cmdLine[$cmdLine[0]]) <> $LAUNCH_PARAMETER Then ; Lancement parallèle
    $NOM = "PERE"
    For $i = 0 To 9
        $DATA[$i] = Run(@AutoItExe&' "'&@ScriptFullPath&'" '&($i+1)&' '&$LAUNCH_PARAMETER, @ScriptDir)
    Next
Else
    $NOM = "FILS"
    $DATA[0] = Number($cmdLine[1])
    $DATA[1] = @AutoItPID
EndIf

; Corps du script
Global $TITRE = "PERE : TOP DEPART !", $X = $DATA[0]*@DesktopWidth/11
If $NOM = "PERE" Then ; Pere crée la clef, lance le top départ (affichage d'une fenêtre), attend la mort des fils, et affiche la valeur
    RegWrite("HKEY_CURRENT_USER\Software\Test", "Increment", "REG_SZ", 0) ; Maximum = 9223372036854775807
    ; On attend les deux fils stables
    Sleep(1000)
    Do
        $exist = True
        For $i = 0 To 9
            $exist = $exist And ProcessExists($DATA[$i])
        Next
    Until $exist = True
    Local $GUI = GUICreate($TITRE,150,100,5,5)
    GUISetState(@SW_SHOW, $GUI)
    Sleep(2000)
    GUIDelete($GUI)
    Do
        $exist = False
        For $i = 0 To 9
            $exist = $exist Or ProcessExists($DATA[$i])
        Next
    Until $exist = False
    Local $resultat = Number(RegRead("HKEY_CURRENT_USER\Software\Test", "Increment"))
    MsgBox(0,"PERE","Valeur en base : '"&$resultat&"'"&@CRLF&"Il y a donc eu "&(10*1000-$resultat)&" pertes.")
Else ; Les fils attendent le top départ du père, incrémentent la valeur de la clef, et se terminent
    ToolTip("Fils N°"&$DATA[0]&" ("&$DATA[1]&") en attente",$X, 5)
    While WinActive($TITRE) = 0
        Sleep(100)
    WEnd
    ; Go
    For $i = 0 To 1000
        ToolTip("Fils N°"&$DATA[0]&" : "&$i&"/1000",$X, 5)
        RegWrite("HKEY_CURRENT_USER\Software\Test", "Increment", "REG_SZ", Number(RegRead("HKEY_CURRENT_USER\Software\Test", "Increment"))+1) ; Maximum = 9223372036854775807
    Next
EndIf

PS: J'ai codé ce truc en 10 minutes, pas sûr que je n'ai pas fait d'erreur de conception, mais ça m'étonnerait, le résultat est très proche de ce qu'on peut observer partout.

En bref, Jshd, si tu peux, aurais tu le temps de modifier le script ci dessus pour me montrer ton concept? ça m'intéresserait de pouvoir mettre en place un véritable jeton de ressource.

Merci d'avance en tout cas.

[ZDS]

@zeshrek: Je pense que le script juste au dessus peut te montrer les soucis qu'engendre les accès concurrents ^^

@sksbir: C'est justement le principe des sémaphores noyau que tu appliques au réseau, malheureusement, je ne vois pas comment implémenter cela dans un script AutoIt. ^^
Surtout que ton algo lui même pose des problèmes d'atomicité (tiens ça existe comme mot ? ^^) : entre le moment où tu sors de la première boucle while et celui où tu écris dans la base de registre, deux processus ont pu voir ce ($DROIT_ECRITURE=0) en même temps, et PAF accès concurrent ^^

Code : Tout sélectionner

while ($DROIT_ECRITURE<>0)
    sleep(random..) ; l'attente d'un délai ALEATOIRE est la clé du succès.
    lire $DROIT_ECRITURE
wend
regwrite(.... $DROIT_ECRITURE,valeur unique de ce script)

Il y a bien un garde fou juste après, mais :
1a) P1 écrit sa valeur dans la clef => Reg = "P1"
1b) P1 lit sa valeur => P1.$x = "P1"
2a) P2 écrit sa valeur dans la clef => Reg = "P2"
2b) P2 lit sa valeur => P2.$x = "P2"
1c) P1 compare la valeur P1.$x à sa valeur => C'est bon, je prend la main
2c) P2 compare la valeur P2.$x à sa valeur => C'est bon, je prend la main aussi
Oups... ^^

(faut pas faire confiance aux sleeps et aux quantum, Windows et son tourniquet peuvent n'en faire qu'à leur tête, il suffit d'un ralentissement tout bête au mauvais moment) Sinon l'idée est bonne ; c'est juste qu'un proc va plus vite qu'une ethernet ^^

EDIT: C'est vrai que le sleep rend la collision beaucoup beaucoup moins probable, mais pas impossible dans le cas d'un ralentissement (il suffit de lancer son navigateur préféré pour cela).
De plus comme tu dis, une seule erreur et c'est l'inter-blocage général. Par contre pour ce que tu appelles la référence temporelle, je n'en ai mis nulle part, le gestionnaire de token s'occupant de donner la main au processus dans l'idéal, et non laisser les processus prendre la main. C'est dans cette optique que le système n'a plus rien à gérer comme valeur pseudo-aléatoire (et donc le pseudo cas particulier qui peut apparaitre).

[sksbir]

@sksbir: C'est justement le principe des sémaphores noyau que tu appliques au réseau, malheureusement, je ne vois pas comment implémenter cela dans un script AutoIt. ^^
Surtout que ton algo lui même pose des problèmes d'atomicité (tiens ça existe comme mot ? ^^) : entre le moment où tu sors de la première boucle while et celui où tu écris dans la base de registre, deux processus ont pu voir ce ($DROIT_ECRITURE=0) en même temps, et PAF accès concurrent ^^

Code : Tout sélectionner

while ($DROIT_ECRITURE<>0)
    sleep(random..) ; l'attente d'un délai ALEATOIRE est la clé du succès.
    lire $DROIT_ECRITURE
wend
regwrite(.... $DROIT_ECRITURE,valeur unique de ce script)

Il y a bien un garde fou juste après, mais :
1a) P1 écrit sa valeur dans la clef => Reg = "P1"
1b) P1 lit sa valeur => P1.$x = "P1"
2a) P2 écrit sa valeur dans la clef => Reg = "P2"
2b) P2 lit sa valeur => P2.$x = "P2"
1c) P1 compare la valeur P1.$x à sa valeur => C'est bon, je prend la main
2c) P2 compare la valeur P2.$x à sa valeur => C'est bon, je prend la main aussi
Oups... ^^

(faut pas faire confiance aux sleeps et aux quantum, Windows et son tourniquet peuvent n'en faire qu'à leur tête, il suffit d'un ralentissement tout bête au mauvais moment) Sinon l'idée est bonne ; c'est juste qu'un proc va plus vite qu'une ethernet ^^

mmm, tu es sûr ? parce que évidemment, le random appliqué dans la boucle ne doit jamais dépasser la valeur du sleep(100). C'est plutot du genre random(1,10)
Si la valeur relue après les 100ms ne correspond pas à ce que le process y a écrit, c'est qu'il y a eu collision ( comme les collisions de paquets en ethernet ).
Maintenant, il est vrai que tout n'est pas implémenté, en particulier le cas où un des process se plante alors qu'il est en train d'écrire ( et du coup, plus personne n'a le droit d'écrire vu que le process planté ne "lâche" pas le droit d'écrire...).
Par ailleurs dans ta démo, j'ai pas suivi où était la référence temporelle ?

Il y a aussi le risque qu'une collision provoque l'écriture d'une valeur qui ne serait reconnue par aucun des process présents..

[jchd]

@ZDS,
Désolé je suis en surcharge (de boulot en retard, pas pondéral -- ça serait plutôt le contraire !) et n'ai pas trop le temps de fabriquer un machin correct.

Maintenant, je te dis tout de go ce que je ferais si j'étais à ta place : une base SQLite (et oui, encore) dont tu es sûr que les qualités ACID sont respectées dans tous les cas. Puisque ce n'est que pour de la répartition de process et de charge de travail (process probablement lents) ce n'est pas gênant. Tu en as pour 20 lignes de codes, à la louche, tu es sûr que c'est stable et ça te permet au passage de stocker/gérer des codes erreur sophistiqués, des infos de reprise, passer des foultitudes de paramètres complexes, avoir un retour de progression, de gérer une arborescence de process, c'est portable sur virtuellement toute architecture hard/soft, etc.

[Tlem]

Je vais essayer de partager comme les autres un avis sur la question.

Techniquement, j'aurais moi aussi utilisé la base de registre ou plus simplement un fichier quelconque.
Le seul truc, c'est que dans ce cas il ne faut absolument aucun plantage, car sinon les clés ne seront pas effacées ...
Cela dit, avec la gestion ci-dessous, il n'y a plus de problème.
Un autre choix, consisterait à utiliser une variable en RAM (voir ici).

Si je suis la logique fonctionnelle de ZDS, nous n'avons que deux solutions (pour l'instant) :

• 1 - Le processus fils annonce qu'il doit fonctionner séquentiellement
  2 - Le processus fils annonce qu'il doit fonctionner en parallèle

Solution :
Etape 1 : La variable, Clé, fichier de communication est initialisé (effacée ou remise à zéro).
Etape 2 : Le fils est lancé par un Run.
Etape 3 : Le père regarde si le processus est bien lancé (ou il attend qu'il soit lancé).
Etape 4 : Le fils déclare la valeur de son mode de fonctionnement (séquentiel, parallèle et éventuellement un autre mode pas encore répertorié ).
Etape 5 : Le père lit la variable en mémoire, la Clé ou le fichier de communication.

• Si 0, alors il continue
  Si 1, alors il patiente en surveillant le processus fils (il est même possible de surveiller la stabilité du processus en rajoutant des contrôles divers ou varié sur la consommation mémoire ou accès disque, etc ... afin de prévenir tout plantage. ).

Techniquement, tant que le processus d'un fils qui doit fonctionner séquentiellement existe, le processus père n'a aucune raison de continuer et donc d'utiliser le système de communication quel qu'il soit.
Donc point besoin de tas de variables ou clés de base de registre ou même d'une gestion complexe de mutex ou de gestion de noms de variables complexe.

Voilà, c'était mon point de vue sur la question. Maintenant, je suis peut être complètement à coté de la plaque, car j'ai décroché sur les explications de ZDS assez rapidement.

[ZDS]

Tlem tu as tout à fait raison sur le principe et la logique. C'est vrai que ce ne sont plus ni le coté séquentiel ni le coté parallèle qui posent problème. Je pense que pour mon template, le problème est résolu.
Les fils peuvent se lancer en type Run ou en RunWait. Les fils n'ont pas à tenir le père de la façon dont ils se lancent.

Ta solution propose de lancer les fils en Run, et fait patienter "artificiellement" le père en ajoutant un système de valeur "externe" (fichier, clef de registres, emplacement RAM, ça reste un ajout).
Je vais garder ma solution de lancer les fils en RunWait, et faire un reboot de chaque fils voulant être en parallèle, c'est plus simple même si pendant une fraction de seconde il y a deux fils identiques en parallèle (négligeable sauf si c'est du gros script, ce que justement j'abhorre, puisqu'il s'agit d'un système distribuée : pleins de petits au lieu d'un seul gros).

Je passe ce topic en [R]ésolu, en attendant que j'arrive à créer une UDF sur la base de ton idée de mémoire en RAM, le tout encapsulé dans un mutex pour éviter les soucis à la source. Quand j'aurai cela, je serai en mesure de proposer un gestionnaire de sémaphore pour la communauté, ce qui devrait en aider quelques uns

Merci pour tout en tout cas !

[Tlem]

Je tiens juste à rajouter que le système que vous adoptez n'écarte pas (pour l'instant) la possibilité qu'un fils séquentiel ce bloque et donc qu'il bloque aussi le père.

[ZDS]

Oui, exact. Mais comme les fils sont conçus de façons à ne pas pouvoir "planter" (coupure du processus si problème, et tâche d'une dizaine de secondes maximum), ça ne pose pas de souci dans mon cas. D'un autre coté, voici une fonction qui peut dépanner si ça arrive :

► Afficher le texte_RunWait

Code : Tout sélectionner

Func _RunWait($program, $workingdir, $timeOut = 0)
    Local $pid = Run($program, $workingdir), $timer = TimerInit(), $delay = $timeOut*1000
    ; Delai avant lancement réel du processus
    While Not ProcessExists($pid) And (TimerDiff($timer) < $delay Or $delay = 0)
        Sleep(100)
    WEnd
    ; TimeOut réel
    While ProcessExists($pid) And (TimerDiff($timer) < $delay Or $delay = 0)
        Sleep(100)
    WEnd
    If ProcessExists($pid) Then Return 0
    Return 1
EndFunc

[Tlem]

Wonderfull !!!