Discussion :

[boubouboy]

Bonjour a tous,

Donc voila tout est dans le titre .
Je vais quand même détailler un peu.
Je dois faire du monitoring de processus enfants depuis un processus père. Pour cela mon processus père possède un handler sur le signal SIGCHLD qui signal la fin d'un processus fils. Sur réception du signal il récupère les données de siginfo_t passé en passé par le signal et les mets dans un FIFO.
Cette FIFO est bloquée et protégée (sémaphore + mutex).
Pour l'instant je n'ai pas de problème mais je sais que je peux tomber dans un cas de deadlock qui est le suivant.

une data est poussée dans la fifo, le sémaphore est augmenté à 1.
la fifo alors en attente sur le sémaphore le réduit a 0, verrouille le mutex récupère la data stockée.

Par malchance un SGCHLD est levé alors que la FIFO n'a pas relâché le mutex
Le handler du signal cherche à prendre le mutex de la FIFO déjà verrouiller par le thread
Le signal reste bloqué car le mutex ne peut être pris et le thread reste bloqué car le signal n'a pas rendu la main.
-> DEADLOCK

Ma question des donc la suivante comment puis-je empêcher ce cas?

P.S. La fifo est un template sur lequel je n'ai pas la main. Je veux dire par la que je ne peux pas m'amuser a bloquer le signal (avant le mutex) puis le débloquer une fois le mutex libéré.

Merci par avance

[Bousk]

Salut,

l'utilisation de mutex est largement plus simple et meilleur avec un objet type guard_lock.

[Matt_Houston]

Par malchance un SGCHLD est levé alors que la FIFO n'a pas relâché le mutex

Si tu es encore dans le handler du SIGCHLD lorsque cela se produit, alors tu n'as pas de crainte à avoir de ce côté là : les signaux suivants du même type vont être bloqués.

En revanche cela met en avant un défaut de conception car ils vont également être fusionnés ! En conséquence tu ne pourras pas récupérer tous les siginfo_t. Tu devrais revoir ton implémentation et utiliser des signaux temps-réel ou alors un procédé de synchronisation dédié.

[boubouboy]

En revanche cela met en avant un défaut de conception car ils vont également être fusionnés ! En conséquence tu ne pourras pas récupérer tous les siginfo_t. Tu devrais revoir ton implémentation et utiliser des signaux temps-réel ou alors un procédé de synchronisation dédié.

Le problème avec les signaux temps réel est qu'il faut les envoyer .
Je fork mon processus père pour lancer des exécutables que je ne contrôle pas ( je ne peux pas rajouter l'envoi d'un SIGRT). Le SIGCHLD est lui envoyé automatique vers le père a la mort du fils, d’où le fait que je me sois orienté de ce coté la.

Effectivement les signaux fusionneront si je suis dans le handler, je reconnais ne pas encore gérer ce problème (comment avoir les infos pour chaque processus), par contre, je gère la destruction de plusieurs fils sur un SIGCHLD (cas de signaux fusionnés) pour la gestion de la table des processus.

Que proposez vous comme procédé de synchronisation dédié?

l'utilisation de mutex est largement plus simple et meilleur avec un objet type guard_lock.

Je ne pense pas que le lock_gard résolve mon problème de deadlock. A partir du moment ou un signal est reçu par mon process, si mon thread a locker le guard de la fifo je me retrouve dans la même situation de deadlock.
D'autre part je n'ai pas la main pour modifier le code de ma fifo

Cordialement,

[Matt_Houston]

Effectivement les signaux fusionneront si je suis dans le handler, je reconnais ne pas encore gérer ce problème (comment avoir les infos pour chaque processus)

Et si tu en trouves une avec les signaux de base, je suis preneur ! Malheureusement je ne pense pas qu'il en existe et je doute que ton problème aie une solution sans action explicite de la part des fils : envoi d'un signal temps réel via sigqueue, modification d'une ressource partagée, écriture dans un fichier / pipe..

Que proposez vous comme procédé de synchronisation dédié?

Les constructions qu'on utilise habituellement en programmation concurrentielle : ressource partagée protégée par sémaphores et mutexes (avec action des fils, donc). Je qualifie ici le procédé de synchronisation de dédié car les signaux ne sont pas à la base prévus pour faire de la communication inter-processus.