Problème de synchronisation des threads avec les sémaphores et signaux

**JohnVist** · 05/06/2015, 15h25

Bonjour,

Après avoir lu et relu (plusieurs fois) la discussion sur "Sémaphore et threads" de #cladoo
et parcourus plusieurs fois l'exemple de la documentation "WD pool de threads"
qui utilise sémaphore et signaux, je n'ai toujours pas réussi à résoudre mon problème.

Mon programme fait la surveillance d'un répertoire RepA et son sous répertoire
SousRepA(certains s'en souviennent

)
Lors d'un ajout de plusieurs fichiers textes avec differents noms dans le sous répertoire SousRepA
le programme doit copier un seul fichier à la fois vers la racine RepA et le renommer
en fichier.txt seul nom obligatoire pour tous les fichiers copié vers la racine.
son contenu est ensuite transféré dans la base de données et seulement à ce moement on copie
le fichier suivant.
j'ai donc essayé de synchroniser la file d'attente avec les sémaphores et signaux, mais
mon programme ne fonctionne toujours pas comme il faut. Le actions se dédoule en désorde comme par
exemple:
- le fichier.txt est suprimmé avant même que son contenu soit copier
-il y a des conflits d'accès à la base de données etc..

voici mon code:

surveillace :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 
ThreadMode(threadSectionCritique)
....
RepIn est une chaîne = "C:RepA"
 
 
MoiMême..Libellé=(MoiMême..Enfoncé?"ON" SINON "OFF")
 
SI BTN_On_Off..Enfoncé = Vrai ALORS
 
	//destruction des anciens sémaphores
	SémaphoreDétruit("SectionCritique")
 
	//on commence par le premier thread
	gnNumThread = 1
 
 
	SémaphoreCrée("SectionCritique",1)
 
	//nous créons deux signaux pour gérer les copies dans les dossiers et base de données
	SignalCrée("copie", signalAutomatique, signalFermé)
	SignalCrée("base",signalAutomatique,signalFermé)
 
	//mise en surveillance du dossier spécifié
	fSurveilleRépertoire(RepIn,_Traitement,fsCréationFichier + fsSuppressionFichier + fsModificationFichier + fsRenommage)
 
SINON			
	// Arrête la surveillance
	fSurveilleStopTout()

gestion des la copie vers RepA et copie dans la base avec plusieurs threads appelant
les procédures copie (EtapeCopie) et et base de données (EtapeDonnées):

les procédures:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
 
PROCEDURE _Traitement(sNomRépertoire est une chaîne, sNomFichier est une chaîne, nTypeChangement est un entier, sParamètre)
 
sMessage est une chaîne
sElément est une chaîne = sNomRépertoire + ["\"] + sNomFichier
 
 
SELON nTypeChangement
CAS fsSuppressionFichier
 
		…….
 
	CAS fsCréationFichier		
		// On teste l'existence du fichier, s'il n'existe pas, c'est un répertoire
		SI fFichierExiste(sElément) = Faux ALORS
			………..
		SINON
 
			SI (sElément [~] "SousRepA") ALORS
			//sMessage = ChaîneConstruit("Le fichier <%1> a été ajouté", sElément)
			//On exécute le thread		
 
			ThreadExécute(csNomThread+gnNumThread,threadNormal,EtapeCopie,sElément)	
 
			SignalAttend("copie")
 
			//On incrémente le numéro du thread en cours
 
			gnNumThread ++					
 
 
 
 
		   SINON
 
 
		   SI fFichierExiste(sElément)=Vrai ALORS
				   ThreadExécute(csNomThread+gnNumThread,threadNormal,EtapeDonnées,sElément)				  
 
				     SignalAttend("base")
 
     //On incrémente le numéro du thread en cours
				   gnNumThread ++	
 
 
		    SINON
 
			FIN
 
 
			FIN
 
		FIN
	CAS fsRenommage
		………
 
	CAS fsModificationFichier
		……..
	AUTRE CAS
		…..
		RETOUR
FIN

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
 
PROCEDURE EtapeCopie(sElément)
 
SignalModifie("copie",signalOuvert)
 
SémaphoreDébut("SectionCritique")
 
	SI fFichierExiste(RepIn + "\fichier.txt")=Vrai  ALORS 
 
		SI fAttributLectureSeule(RepIn + "\fichier.txt",Faux) = Faux ET ErreurDétectée = Faux ALORS
			ListeAjoute(LISTE_Fichiers,"Lecture seule enlevée!")
		SINON
			Erreur(ErreurInfo(errMessage))
		FIN
 
		SI fSupprime(RepIn + "\fichier.txt") = Vrai 
 
			ListeAjoute(LISTE_Fichiers,"Fichier supprimé!")
		SINON
			Erreur("impossible de supprimer le fichier fichier.txt",ErreurInfo(errMessage))
		FIN
 
 
		SI fCopieFichier(sElément, RepIn + "\fichier.txt") =Vrai ALORS  
 
		SINON
			Erreur(ErreurInfo(errMessage))
		FIN
 
	ListeAjoute(LISTE_Fichiers,"signal reçu :-)")
 
	SINON
		SI fCopieFichier(sElément, RepIn + "\fichier.txt") =Vrai ALORS 
 
			ListeAjoute(LISTE_Fichiers,"Fichier copié B!")
		SINON
			Erreur(ErreurInfo(errMessage))
		FIN
 
FIN
 
SémaphoreFin("SectionCritique")
 
 
 
 
 
 
 
PROCEDURE EtapeDonnées(sElément)
 
 
 
	SignalModifie("base",signalOuvert)
 
 
SémaphoreDébut("SectionCritique")
 
		SI HImporteTexte(BASE, sElément, "Nfichier, Agence, Numéro, Nom, Prénom, Adresse", "," + Caract(127) + """" + Caract(127) + RC + Caract(127) + ".", hImpCréation) = Vrai 
 
 
			ListeAjoute(LISTE_Fichiers,"Entrée zone base de données!")
 
								SINON
 
			Erreur(ErreurInfo(errMessage))
		FIN
 
 
 
 
 
   SémaphoreFin("SectionCritique",1)

Question : pourquoi mon programme n'arrive pas à synchroniser les threads ?

Merci d'avance.

**WDKyle** · 05/06/2015, 20h42

Bonsoir,

Hum... Tu peux nous expliquer simplement ce que tu souhaite comme résultat stp ? Car je pense qu'on peut faire autrement et plus simple qu'en synchronisant plusieurs thread.

**jurassic pork** · 06/06/2015, 00h51

hello,
je n'ai peut-être pas bien compris ton problème, mais tu peux essayer d'utiliser une pile.

1 - Déclarer une pile dans le code de la fenêtre ou le code du programme

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

MaPile est une Pile de chaînes

2 - Dans la procédure de surveillance tu empiles les noms de fichiers créés dans la pile :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Empile(MaPile,NomFichier)

3 - Tu as une procédure automatique qui s'exécute tous les x secondes (ou moins) et qui teste si il y a quelque chose dans la pile. Si oui on dépile et on traite le fichier dépilé :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
ElementPile est une chaîne
SI MaPile..Occurrence <> 0 ALORS 
  Dépile(MaPile,ElementPile)
  // traitement du fichier ElementPile
FIN

Ami calmant, J.P

**tatayo** · 06/06/2015, 09h26

Bonjour,
Ici j'aurai plutôt utilisé une file, puisqu'il s'agit de gérer une file d'attente. Ainsi les fichiers seront traités dans l'ordre d'arrivée (FIFO).

Tatayo.

**frenchsting** · 08/06/2015, 08h58

Il me semble qu'on t'avait donné des pistes lors de la discussion précédente.

Je ne pense pas qu'un ensemble de threads soit nécessaire (et encore). Un seul suffit. Avec un flistefichier associé ou non à une procédure. Tu vas, fichier par fichier, les traiter. Le truc est de ne pas relancer le traitement si le traitement précédent n'est pas terminé. L'utilisation d'un booléen est indiquée dans ce cas.

Le et encore correspondrait à un programme indépendant qui ferait le traitement (automate).

**JohnVist** · 08/06/2015, 09h59

Bonjour,

@WDKyle je souhaite mettre un répertoire et ses sous répertoires sous surveillance, et quand on dépose
plusieurs fichiers dans l'un des sous répertoires, le programme doit gérer la file d'attente
avec la contrainte de copier un seul fichier dans le répertoire racine, et transférer son contenu dans la base
de données.

@jurassic pork & tatayo :
-j'ai premièrement essayé le programme avec une file (pile), puisqu'il s'agit
d'un programme qui tourne 24/24, comment détecter et traiter uniquement la liste des derniers fichiers
ajoutés ?
- quand on défile ou dépile, il y a une modification de la file d'attente, seulement comment accéder à l’élément
défilé (dépilé) ?

@frenchsting oui justement j'avais plusieurs pistes, celle des threads me semblait la plus adéquate, seulement
mon programme ne traite pas bien la synchronisation avec un ou plusieurs threads.

Merci à vous tous!

**tatayo** · 08/06/2015, 10h34

Je dirai qu'il faut jeter un œil à l'aide en ligne... Tout y est clairement expliqué, exemple à l'appui.

Tatayo.

**jurassic pork** · 08/06/2015, 12h58

hello,
as-tu réalisé ce que je proposais :

1 - Dans le code de surveillance du répertoire , à chaque fois qu'il y a un nouveau fichier tu empiles (enfiles) le fichier détecté. Donc tu te retrouves avec une pile (file) avec les nouveaux fichiers arrivés.

2 - Il y a un timer (procédure automatique) qui tourne en parallèle et qui regarde si il y a quelque chose dans la pile (file). Si il y quelque chose , tu dépiles (défiles) un des éléments et tu fais le traitement approprié. Cet élément disparaît de la pile (file) dès que tu l'as dépilé (défilé) . Donc au prochain passage si il reste des éléments où qu'il y a des nouveaux éléments ils seront traités.

Il faut que la période du timer soit supérieure au temps de traitement du fichier ou alors il faut qu'il y ai une variable (flag) qui dise qu'il y a encore un traitement en cours et donc de pas dépiler (défiler) un autre élément de la pile dans qu'il y a un traitement en cours.

Ami calmant, J.P

**tatayo** · 08/06/2015, 14h13

Envoyé par jurassic pork

Il faut que la période du timer soit supérieure au temps de traitement du fichier ou alors il faut qu'il y ai une variable (flag) qui dise qu'il y a encore un traitement en cours et donc de pas dépiler (défiler) un autre élément de la pile dans qu'il y a un traitement en cours.

Il est inutile de passer par une variable, car une propriété des (p/f)iles permet de savoir si l'ajout est terminé.
Il suffit donc de faire une boucle en testant cette variable, puis dans cette boucle une deuxième boucle qui de(p/f)ile l'élément (avec un petit time-out), et le tour est joué.

Tatayo.

**JohnVist** · 09/06/2015, 17h18

Envoyé par jurassic pork

hello,
as-tu réalisé ce que je proposais :

1 - Dans le code de surveillance du répertoire , à chaque fois qu'il y a un nouveau fichier tu empiles (enfiles) le fichier détecté. Donc tu te retrouves avec une pile (file) avec les nouveaux fichiers arrivés.

2 - Il y a un timer (procédure automatique) qui tourne en parallèle et qui regarde si il y a quelque chose dans la pile (file). Si il y quelque chose , tu dépiles (défiles) un des éléments et tu fais le traitement approprié. Cet élément disparaît de la pile (file) dès que tu l'as dépilé (défilé) . Donc au prochain passage si il reste des éléments où qu'il y a des nouveaux éléments ils seront traités.

Bonjour,

Oui j'ai essayé cette idée et ça marche

En ce qui concerne la variable, je n'ai pas utilisé de variable ( flag ??), j'ai quand même mis le temps du timer de 2 secondes ce qui est énorme en terme d'attente. C'est pour m'assurer que le traitement en cours de l'élément de la file soit terminé.

Par ailleurs je n'ai pas bien compris l'idée de Tatayo sur AjoutTerminé

**tatayo** · 09/06/2015, 19h08

C'est simple: il faut une condition de sortie de la boucle qui traite du contenu de la file.
Mais quelle condition ? Le fait que la file soit vide n'est pas suffisant, car il est possible que le "remplissage" soit plus lent que le "traitement".
C'est là que cet attribut entre en jeux.
La boucle principale remplie la file sans se poser de question. Une fois ce "remplissage" terminé, elle passe à vrai la propriété ..AjoutTerminé.

Ensuite dans le thread de traitement, il faut faire deux boucles imbriquées:

La première qui boucle tant que ..AjoutTerminé = faux, avec une petite tempo entre chaque itération, par exemple 1/10 de seconde

La deuxième imbriquée dans la première, qui boucle tant qu'il y a des éléments dans la file

Ainsi si la tempo dans le traitement n'intervient que si ce dernier "prend de l'avance" sur le remplissage de la liste, et travaille à pleine vitesse le reste du temps.
Et le thread se termine tout seul quand il n'y a plus rien à faire, c'est à dire que la liste est vide et le restera.

Tatayo.

**JohnVist** · 11/06/2015, 10h44

Bonjour,

si je comprends bien, quand le thread qui enfile n'a pas mis ...AjoutTerminé=faux et que la file est vide il se pourrait que je loupe le traitement de certains fichiers.
Pour l'instant puisque la surveillance détecte chaque fichier ajouté, j'ai mis le thread qui enfile dans la boucle de la surveillance. Par ailleurs, toute les 2 seconde j'exécute un Timer sur la procédure qui
qui vérifie si la file est vide et défile chaque élément de la file pour faire un traitement.

**tatayo** · 11/06/2015, 15h03

Ce n'est pas tout à fait ça. La propriété AjoutTerminé permet aux threads qui lisent le contenu de la file de savoir qu'il n'y aura plus d'ajout dans la file, et donc qu'il peuvent se terminer.
C'est ce qui permet de faire la distinction entre une file vide "car le remplissage ne suit pas" et une file vide "car le traitement est terminé".

Je ne vois pas pourquoi tu raterais le traitement de certains fichiers. Tant que le processus voit des fichiers à traiter, il les ajoutent dans la file sans se demander si le(s) thread(s) de traitement suit(vent) le rythme. Une fois que tous les fichiers ont été ajoutés dans la file, ..AjoutTerminé passe à vrai.
Et le(s) thread(s) en question boucle(nt) en lisant le contenu de la file, si contenu il y a, tant que la propriété ..AjoutTerminé = faux. Sinon il(s) se met(tent) en attente pendant x centièmes de secondes, histoire de ne pas consommer de CPU dans le vent.

Bref la propriété agit comme le signal "Quand vous aurez terminé, vous pourrez vous arrêter !".

Tatayo.

**JohnVist** · 11/06/2015, 15h51

Ok c'est plutôt une question d'optimisation du travail du CPU plutôt que de louper des traitements, j'essayerais donc les 2 boucles.
Merci

Problème de synchronisation des threads avec les sémaphores et signaux [WD20]

WinDev

Discussions similaires

Partager

Partager