Sémaphore et threads

Bonjour,

Pour ma culture personnelle :roll: je m'intéresse au Threads et aux Sémaphores, en fait j'ai plusieurs fonctions lancées par des threads et ne souhaite pas qu'elles s'exécutent en même temps (je veux être certain que lorsqu'une se lance, aucune des autres n'est en court).

J'ai essayé de traduire ça par un exemple avec 2 fonctions identiques lancées par threads qui écrivent l'heure dans 2 champs distincts.

Est-ce que ce code induit l'exécution d'une fonction à la fois, sans "chevauchement" ou je me plante ?


Code d'appel

Code:

---

1 2 3 4

SémaphoreCrée("ZoneCritique",1,0,partageAucun) ThreadExécute("Thread1",threadContexteGlobal,AfficheHeure) ThreadExécute("Thread2",threadContexteGlobal,AfficheHeure2)

---

Procédure 1

Code:

---

1 2 3 4 5 6 7 8 9 10

PROCEDURE AfficheHeure() i est un entier =1 TANTQUE i=1 SI SémaphoreDébut("ZoneCritique") = Vrai ALORS SAI_Heure = HeureSys() SémaphoreFin("ZoneCritique") ThreadPause(1000) // endort le Thread 10 secondes FIN FIN

---

Procédure 2

Code:

---

1 2 3 4 5 6 7 8 9 10

PROCEDURE AfficheHeure2() i est un entier =1 TANTQUE i=1 SI SémaphoreDébut("ZoneCritique") = Vrai ALORS SAI_Heure2 = HeureSys() SémaphoreFin("ZoneCritique") ThreadPause(500) // endort le Thread 5 secondes FIN FIN

---

Merci

Question supplémentaire : si j'appelle manuellement des procédures (par clic bouton par exemple) puis-je également m'assurer qu'elles ne vont pas se lancer si l'une de mes procédures est en cours ?

J'ai essayé ce code:
Sur clic d'un bouton dans la même fenêtre où sont lancés les threads ci-avant

Code:

---

1 2 3 4 5

SI SémaphoreDébut("ZoneCritique") = Vrai ALORS Trace("TEST") SémaphoreFin("ZoneCritique") FIN

---

mais à tous les coups mon message s'affiche, est-ce dû au fait que le laps de temps entre SémaphoreDébut et SémaphoreFin est très court (de l'ordre du centième de seconde) ?

Merci

Je me réponds moi même concernant le second point :
En effet en rajoutant la ligne en gras, mon message ne s'affiche pas à tous les coups (quand il ne tombe pas dans les 5 secondes entre le SémaphoreDébut et SémaphoreFin)

Procédure 1

Code:

---

1 2 3 4 5 6 7 8 9 10 11

PROCEDURE AfficheHeure() i est un entier =1 TANTQUE i=1 SI SémaphoreDébut("ZoneCritique") = Vrai ALORS SAI_Heure = HeureSys() ThreadPause(500) // endort le Thread 5 secondes SémaphoreFin("ZoneCritique") ThreadPause(1000) // endort le Thread 10 secondes FIN FIN

---

La première question est toujours d'actualité :mrgreen:

Bonsoir,

Première fois que je vois SémaphoreDébut() utilisé comme çà :

Code:

---

SI SémaphoreDébut("ZoneCritique") = Vrai ALORS

---

Le principe est qu'avec un simple :

Code:

---

SémaphoreDébut("ZoneCritique")

---

Juste avant le code à ne pas exécuter en simultanée suffit ;) Du moins, je fais comme çà ! C'est peut-être là ton soucis...

bonjour,

regarde du côté de l'exemple didactique WD pool de threads qui utilise les sémaphores.

Ami calmant, J.P ;)

Bonjour et merci pour vos réponses.

@damien.c : en fait c'est enr regardant l'aide que j'ai vu que cette fonction renvoie un booléen si la zone critique est libre, ça me permet d'afficher un message si un thread essaye d'y accéder alors qu'auncune place n'est disponible.

@jurassic pork : oui justement je me suis "inspiré" du contenu de cet exemple.

@tous :
- est-ce que mes placements de début de zones critiques sont corrects (j'ai encore du mal à valider que mon code est juste) ?
- si j'utilise une procédure appelée par clic sur un bouton : est-ce que l'exécution de la procédure se met en file d'attente pour attendre la libération d'une place dans la zone critique et dans ce cas elle se lance automatiquement OU la commande est perdue jusqu'au nouvel appel sur évènement clic ?

Merci !

Citation:

---

Envoyé par cladoo

- est-ce que mes placements de début de zones critiques sont corrects (j'ai encore du mal à valider que mon code est juste) ?
- si j'utilise une procédure appelée par clic sur un bouton : est-ce que l'exécution de la procédure se met en file d'attente pour attendre la libération d'une place dans la zone critique et dans ce cas elle se lance automatiquement OU la commande est perdue jusqu'au nouvel appel sur évènement clic ?

Merci !

---

Bonjour,
Alors dans l'ordre:
Oui, sauf pour la pause du thread après execution. Si la procédure n'accède pas au thread, elle tourne en boucle sans pause. Mais c'est peut-être voulu ?
Dans l'exemple l'appel se met en attente, car tu n'as pas spécifié de durée d'attente maximale.

Tatayo.

Bonjour tatayo,

Citation:

---

Envoyé par tatayo

Bonjour,
Alors dans l'ordre:
Oui, sauf pour la pause du thread après exécution.

---

La pause (après le SémaphoreFin) qui sert à simuler un timer : je ne sais pas où la placer ?
L'autre pause (celle entre SémaphoreDébut et SémaphoreFin) sert à simuler des traitements longs : l'affichage de l'heure dans un champs prends 1 centième de seconde et ça ne suffisait pas pour valider mon traitement.

Citation:

---

Envoyé par tatayo

Si la procédure n'accède pas au thread, elle tourne en boucle sans pause. Mais c'est peut-être voulu ?
Dans l'exemple l'appel se met en attente, car tu n'as pas spécifié de durée d'attente maximale.
Tatayo.

---

La procédure appelée sur évènement clic tourne en boucle si elle n'accède pas à la zone critique ? ça veut dire qu'elle va s'exécuter autant de fois qu'elle a cherché à rentrer dans la zone critique une fois celle-ci libérée ?

En fait ce que je voudrais faire :
- Procédure 1 accède à la zone critique via son thread, tant qu'elle n'a pas terminé son exécution : interdiction à Procédure 2 d'y accéder et donc de se lancer. Procédure 1 se termine, elle "rend la main"
- Procédure 2 qui a tenté d'accéder plusieurs fois à la zone critique (tentatives rythmées par la simulation du Timer) voit que l'accès est libre : elle s'exécute. Pendant ce temps : Procédure 1 ne peut pas y accéder car c'est Procédure 2 qui a pris l'unique "Ticket".
- Pendant que Procédure 1 ou Procédure 2 sont en exécution : les évènements sur clic appelant des procédures demandant l'accès à la zone critique ne peuvent pas y accéder (un message spécifie cette impossibilité) elles ne se mettent pas en file d'attente, leur tentative est perdue (éventuellement paramétrable : comment ?) et attendent un autre évènement sur clic pour retenter leur chance.

A votre avis, mon code permet-il de faire ça ? Sinon quelles modifications dois-je lui apporter ?

PS : dans la réalité les chevauchements seront a priori impossibles (exemple : exécution toutes les 1h pour l'une, toutes les 2h30 pour l'autre) , mais je préfère éviter qu'il y en ait.

Merci !

Je viens de rajouter un temps d'attente de 0 pour le Sémaphore (cf commentaire de tatayo), j'ai l'impression que ça fonctionne :

Code:

---

SémaphoreDébut("ZoneCritique",0)

---

EDIT : du coup, comme les appels des Procédures1 et 2 seront peu fréquents, pour ne pas perdre leur tentative leur zone critique peut être paramétrée avec un temps d'attente infini. En revanche pour les appels 'sur clic', avec le paramètre 0 : on informe l'utilisateur qu'il devra ré-essayer dans un moment, (pas d'exécution différée)

Qu'en pensez-vous ?

Bonjour,

Je n'ai lu que la 1ère question, mais déjà 3 remarques :
- Un mutex ferait l'affaire : SectionCritiqueDébut/SectionCritiqueFin
- Pour modifier l'interface (SAI_Heure), le mieux reste le thread principal : ExécuteThreadPrincipal (WD17 uniquement, mais on peut faire la même chose avec un SendMessage)
- Enfin, sachez que WinDev met par défaut une section critique autour de chaque fonction, ce qui est généralement inutile et indésirable (ça ne protège que la fonction d'elle même, ça ne protège pas une ressource accédée par la fonction). cf. ThreadMode

PS. Autre remarque : je ne vois même pas de ressource partagée dans votre code, ce sont 2 heures différentes, donc aucun raison de synchroniser (à part que l'accès à l'IHM depuis un thread secondaire c'est pas fiable)


PPS. OK, je viens de comprendre que vous voulez un time-out + un message en cas d'échec, d'où le sémaphore. Cependant, quand on synchronise l'accès aux ressources, et uniquement ça, on a rarement de longs blocages et on a rarement besoin d'abandonner. C'est le principe même de la parallélisation, sinon à quoi bon...

Bonjour,

en réalité, l'exemple illustrant ma demande ne reflète pas mon réel besoin, les procédures que je compte appeler dans mes threads peuvent prendre plusieurs secondes d'exécution et je ne voudrait pas qu'elles puissent se chevaucher, tout en pouvant s'exécuter périodiquement dans la journée sans bloquer l'IHM ou le reste. L'appel de ces procédures ne modifie pas l'interface mais lit/écrit dans différentes bases de données : dans ce cas l'utilisation de ExécuteThreadPrincipal est-elle tout de même préférable aux thread secondaires ?

Vous parlez de synchroniser l'accès aux ressources : mais en effet je n'ai pas besoin de cela, est-ce que mon code induit une synchronisation ? Je pensais que cela nécessitait l'utilisation de ThreadEnvoisignal et ThreadAttendSignal ?

Je veux pas être lourd, mais vous êtes certain que vos traitements ne sont pas parallélisables ? Pour l'instant vous n'avez pas dit pourquoi.

Citation:

---

L'appel de ces procédures ne modifie pas l'interface mais lit/écrit dans différentes bases de données : dans ce cas l'utilisation de ExécuteThreadPrincipal est-elle tout de même préférable aux thread secondaires

---

Non, cette fois c'est OK pour des threads secondaires, et même recommandé.

Citation:

---

Vous parlez de synchroniser l'accès aux ressources : mais en effet je n'ai pas besoin de cela, est-ce que mon code induit une synchronisation ? Je pensais que cela nécessitait l'utilisation de ThreadEnvoisignal et ThreadAttendSignal ?

---

Quand je parle de partage de ressources, c'est au sens général, mais ça concerne surtout des variables, comme par exemple un tableau en mémoire, car pour le reste ce n'est pas forcément à vous de synchroniser. Et quand je parle de synchro, ça inclut les mutex et sémaphores, car s'arrêter pour attendre qu'un autre thread ait débloqué un mutex c'est de la synchro au même titre qu'attendre un signal.

2 exemples :
1. J'ai 2 threads qui écrivent des lignes dans un log. Je dois m'assurer que chaque thread écrit une ligne entière de manière isolée ("ligne1<RC>ligne2<RC>" et pas "ligligne2<RC>ne1<RC>" par exemple), donc j'encadre avec un mutex (ceci dit, c'est peut-être déjà le cas dans fEcritLigne, et puis s'est écrit par blocs)
2. J'ai un thread qui fait POUR i _A_ TableauOccurrence(monTableau) ..., et un autre qui fait TableauSupprime(monTableau, 1). Je dois encadrer la boucle et le TableauSupprime avec un mutex (section critique), sinon le TableauOccurrence qui a été évalué au début peut devenir faux pendant la boucle et on accède à un indice invalide.

Citation:

---

Je veux pas être lourd, mais vous êtes certain que vos traitements ne sont pas parallélisables ? Pour l'instant vous n'avez pas dit pourquoi.

---

Vous ne l'êtes pas (lourd), au contraire votre avis m'est précieux. Cela concerne l'utilisation des connexions (cf Topic sur lequel nous avons échangé hier). Vous m'avez répondu d'utiliser des Requêtes pour gérer mon problème, mais comme je me suis entre temps intéressé aux Sémaphores + Threads j'ai décidé de partir sur cette solution.

Citation:

---

Et quand je parle de synchro, ça inclut les mutex et sémaphores, car s'arrêter pour attendre qu'un autre thread ait débloqué un mutex c'est de la synchro au même titre qu'attendre un signal.

2 exemples :
1. J'ai 2 threads qui écrivent des lignes dans un log. Je dois m'assurer que chaque thread écrit une ligne entière de manière isolée ("ligne1<RC>ligne2<RC>" et pas "ligligne2<RC>ne1<RC>" par exemple), donc j'encadre avec un mutex (ceci dit, c'est peut-être déjà le cas dans fEcritLigne, et puis s'est écrit par blocs)
2. J'ai un thread qui fait POUR i _A_ TableauOccurrence(monTableau) ..., et un autre qui fait TableauSupprime(monTableau, 1). Je dois encadrer la boucle et le TableauSupprime avec un mutex (section critique), sinon le TableauOccurrence qui a été évalué au début peut devenir faux pendant la boucle et on accède à un indice invalide.

---

Vous disiez plus haut que chaque fonction est encadrée implicitement par Windev d'une zone critique : du coup est-ce que ça n'évite pas ce genre de désagrément ?

Concernant les signaux, si j'ai bien compris, c'est surtout utile pour faire démarrer plusieurs Threads en même temps c'est bien ça ? Là du coup je suis surtout intéressé par la possibilité de différer ou non l'exécution d'une fonction lorsque son "timer" lui demande d'accéder à la zone critique, en ce sens les signaux implicites des sémaphores (début et fin) me sont suffisant.

Citation:

---

Envoyé par cladoo

Vous m'avez répondu d'utiliser des Requêtes pour gérer mon problème, mais comme je me suis entre temps intéressé aux Sémaphores + Threads j'ai décidé de partir sur cette solution.

---

2 connexions sont indépendantes. S'il y a de la synchro à faire, ça sera en réalité des transaction isolées ou des blocages sur la base de données. Il ne faut pas oublier qu'une base de données peut être accédée par plusieurs threads, mais aussi plusieurs processus, sessions, machines...
Si vous utilisez les buffers de fichiers, vous pourriez avoir besoin de synchro pour changer de connexion :

Code:

---

1 2	MonFichier.Rub = "Bob" HModifie(MonFichier)

---

Mais là encore, il serait intéressant de voir si on peut pas faire un HChangeConnexion par thread en contexte indépendant. J'ai pas eu le temps de tester. Sinon, je préfère largement utiliser des requêtes que polluer le code avec de la synchro pas réellement utile.

Citation:

---

Envoyé par cladoo

Vous disiez plus haut que chaque fonction est encadrée implicitement par Windev d'une zone critique : du coup est-ce que ça n'évite pas ce genre de désagrément ?

---

Exemple :

Code:

---

1 2 3 4

PROCEDURE Bobby() POUR i = 1 _A_ TableauOccurrence(gtabBetty) Trace(gtabBetty[i] FIN

---

Code:

---

1 2 3

PROCEDURE Billy() TableauSupprimeTout(gtabBetty) ChaîneVersTableau(fChargeTexte("benny.txt"), gtabBetty)

---

Avec la synchro par défaut :
L'entrée de 2 threads dans Bobby est interdite.
L'entrée de 2 threads dans Billy est interdite.
Mais on peut avoir un thread dans Bobby et un dans Billy.
Si Billy s'exécute pendant la boucle de Bobby, Bobby va planter.

C'est pour ça qu'on protège des ressources, et non des fonctions.

Citation:

---

Envoyé par cladoo

Concernant les signaux, si j'ai bien compris, c'est surtout utile pour faire démarrer plusieurs Threads en même temps c'est bien ça ? Là du coup je suis surtout intéressé par la possibilité de différer ou non l'exécution d'une fonction lorsque son "timer" lui demande d'accéder à la zone critique, en ce sens les signaux implicites des sémaphores (début et fin) me sont suffisant.

---

Les signaux sont utiles à tout type de séquencement, l'exemple le plus commun pour moi est quand un thread en lance un autre et attend de savoir si le thread lancé a réussi son init avant de passer à autre chose. Le 2ème thread envoie donc un signal pour indiquer qu'il a fini son init, et le 1er attend le signal + le thread. Si c'est le signal qui répond, c'est OK, si c'est le thread c'est un échec. Par exemple une fonction "LanceCapture" qui enregistre un son et qui renvoie Vrai si la capture est correctement démarrée.

PS. J'ai corrigé quelques unes de mes fautes de frappe

Toutes vos explications sont vraiment intéressantes et pertinentes, je vous dis bravo! :ccool:

Pour le HChangeConnection indépendant je n'ai non plus eu l'occasion de tester (puisque je suis parti sur les sémaphores), mais c'est en effet plus simple d'utiliser des requêtes si cela fonctionne.

Bonjour,

Ca y est, j'ai testé le HChangeConnexion dans les threads.
Ca marche parfaitement, dans chaque thread j'associe tous les fichiers de l'analyse à une connexion différente.
Ne pas oublier l'option threadUtiliseHyperfile.
Et je le répète, quand il s'agit d'accès à une base de donnée, c'est pas de la synchro de thread dont on a besoin, mais des transactions isolées ou des blocages, ou rien du tout selon les cas.

Citation:

---

Envoyé par Hibernatus34

Bonjour,

Ca y est, j'ai testé le HChangeConnexion dans les threads.
Ca marche parfaitement, dans chaque thread j'associe tous les fichiers de l'analyse à une connexion différente.
Ne pas oublier l'option threadUtiliseHyperfile.
Et je le répète, quand il s'agit d'accès à une base de donnée, c'est pas de la synchro de thread dont on a besoin, mais des transactions isolées ou des blocages, ou rien du tout selon les cas.

---

Bonjour,

je viens de tester : 2 Threads (avec timer) qui lancent chacun en parallèle 2 fonctions d'écriture dans 2 bases différentes (description des connexions embarquées dans les fonctions d'écriture) + une fonction d'écriture dans la base courante (décrite au niveau du projet seulement, pas dans cette troisième fonction d'écriture), cette dernière fonction est appelée sur évènement clic. J'ai utilisé l'option threadUtiliseHyperfile dans l'appel des threads.

Résultat : identique à Hibernatus34, ça marche parfaitement sans utiliser de Sémaphores, le contexte hyperfile lié à la connexion est bien respecté dans chaque thread !

Adieux les Sémaphores et merci à Hibernatus34 pour le temps passé sur mon problème. ;)