Bonjour
 
Pour un de mes tp, je dois faire communiquer des threads par des signaux. Cependant, mon tp m'oblige à utiliser le signal SIGCONT. Je m'explique.

 
Donc en gros, je voudrais savoir si c'est possible d'utiliser une fonction avec SIGCONT du père vers le thread et une autre fonction avec SIGCONT du thread vers le père ?

Beuark, quelle horreur, on n'utilise pas de signaux entre threads, ce n'est pas du tout portable, et rien ne dit que ça marchera dans une version prochaine de la glibc.
 
Essaye plutôt de voir du côté des conditions (pthread_cond_init) ou des mutex (pthread_mutex_init).

Je peux utiliser des processus plutot que des threads mais je dois utiliser des SIGNAUX.  
Par contre, comment je peux faire pour choisir quel processus je veux exécuter au moment X. Parce que ce que je dois faire, c'est un genre d'ordonnanceur et il faut donc que j'autorise l'exécution d'un seul processus à la fois et après un quantum de temps, je le mets en attente, je passe au suivant etc...

Je vois ça, justement les fonctions de style mutex, sémaphores et conditions des threads, ça sert à ça. Dans l'implémentation LinuxThreads, tout ça est fait à base de signaux, mais c'est assez compliqué (et c'est l'implémentation la plus crade des threads POSIX).
 
Bref, tout ça ne répond pas à ta question. Je pense que le plus simple, c'est de faire avec des bêtes fork. Avant de faire le fork, tu mets bien le pid du père dans une variable avec getpid, comme ça tu peux faire un kill dessus plus tard (ou alors tu utilises getppid). Le fork retournant au père le pid du fils, il peut lui envoyer un signal sans problème.

[jfdsdjhfuetppo]--Message édité par Jar Jar--[/jfdsdjhfuetppo]

Tu es dans le même process. Ce n'est pas getppid (c'est bien le père ) dont tu as besoin, mais le pid du process dans lequel tu te trouves.

Je pensais que je pouvais éviter d'utiliser des fork() mais j'ai bien peur que ce ne soit pas possible. Il ne me reste plus qu'à me taper pas mal de code pour essayer de trouver un moyen de faire ce foutu tp.
C'est assez le bordel car j'ai des notions de processus, algorithmes de tri, lecture de fichier et répertoire, utilisation de tubes nommées, segment de données et tout ça en temps partagé ! La joie quoi !

La vache ! C'est pas des TP de tapettes, qu'on vous fait faire
 
En fait, le problème avec les threads et les signaux, c'est que la notion de signal n'a pas lieu d'être pour un thread, vu que dans la norme POSIX tous les threads sont des contextes d'exécution du même processus (avec donc le même pid).
Seule l'implémentation linux déroge à cette règle.

 
Donc si je suis sous Linux, ça pourrait marcher alors mon affaire de thread ?

Ça pourrait marcher. Je ne te le conseille vraiment pas, parce que ça peut donner tout et n'importe quoi.
En particulier, rien ne te garantit que le thread que tu as lancé avec pthread_create sera effectivement le fils du premier thread, au sens des getpid...

Ouais c'est vrai ! Je prendrai pas de chance et je vais essayer de faire qqchose avec les fork(). Reste à savoir comment m'amuser à gérer tous les fils en même temps. Parce que de la façon mon TP fait, j'ai au moins 6 processus fils plus le père.
 
Yeah !

Auquel cas, soit tu t'arranges pour que les fils n'aient pas à communiquer entre eux mais seulement avec le père, soit tu utilises un segment de mémoire partagée, soit tu trouves une sale combine : je me souviens avoir utilisé jadis une cascade de tubes récursive entre fils pour faire remonter les pids jusqu'au père. Ça marchait bien (je rigole rien que de repenser à cette idée).

1) Je vais avoir un nombre de processus variables (entre 2 et 20)à chaque exécution. Comment je fais pour en créer autant que je veux tout en enregistrant leur pid à chaque fois car il faut que je puisse les appeler par la suite ?
 
2) Segment de mémoire partagée ? J'ai de la difficulté à bien saisir ce que ça fait car j'ai rien dans mes notes de cours là-dessus. Quelqu'un a un lien intéressant là-dessus ?
 
Merci.

1) Je vais avoir un nombre de processus variables (entre 2 et 20)à chaque exécution. Comment je fais pour en créer autant que je veux tout en enregistrant leur pid à chaque fois car il faut que je puisse les appeler par la suite ?
 
Bah tu fais une boucle, et tu ranges les pids dans un tableau au fur et à mesure de la création des fils.
 
 
2) Segment de mémoire partagée ? J'ai de la difficulté à bien saisir ce que ça fait car j'ai rien dans mes notes de cours là-dessus. Quelqu'un a un lien intéressant là-dessus ?
 
Regarde du côté de shmget, mais je ne te conseille pas de t'en servir si tu peux faire autrement, parce que c'est vraiment tordu. Ça permet de partager une zone de mémoire entre plusieurs processus.

[jfdsdjhfuetppo]--Message édité par Jar Jar--[/jfdsdjhfuetppo]

 
Bon je viens de relire les notes de cours et normalement je pense que je peux faire ça. Mais par contre, après comment je fais pour dire que je veux que mon processus X excéute la fonction que je veux ? Est-ce que ça marcherait ça :
 

Avec ça, tu n'auras pas N processus, mais 2^N...
 
 
C'est plutôt :

Ouais, c'est pas pire ton affaire ! Je pense que je vais m'en inspirer    
 
Par contre, je ne comprends pas trop bien l'utilisation des segments de données. Je dois attacher le segment à un processus, inscrire des données dedans et les trier puis après un quantum de temps, je fais un backup et j'exécute un autre processus qui fait la même chose. Mes interrogations se situent par rapport aux segments : quel est leur utilité (à quoi ça sert?) et comment les utiliser (avec les paramètres de clé et tout le tralala) ?
 
Je sens que je vais virer dingue !

[jfdsdjhfuetppo]--Message édité par Matheo--[/jfdsdjhfuetppo]

Les segments de mémoire partagée, c'est un truc très compliqué pour faire des choses simples. C'est pour ça que depuis on a inventé les threads. (Pareil pour les signaux d'ailleurs, depuis on a inventé les mutex.)
Ça sert à avoir une zone de mémoire commune à plusieurs processus. Dans cette zone de mémoire, tu mets des données, par exemple sous forme d'un tableau. Tout le problème après coup est qu'il faut un moyen aux différents processus d'accéder à la même zone de mémoire : c'est la clé.

Ça y est, je commence à y voir clair dans tout ça ! C'est pas évident mais je pense que je vais parvenir à me débrouiller. Je te remercei très fort pour toutes tes indications et si t'habitais proche de chez moi, je te payerais volontiers une bière.

Je t'en prie.

Au fait, t'habites dans quel coin ?

c01n c01n.
 
Euh, pardon, Lyon.

Moi je suis à Montréal ! 5000 km pour boire une bière ça fait un peu loin quand même !

Ouaip ! Surtout que je ne bois pas de bière !

Juste une petite précision concernant la création des processus

 
1) Pourquoi les instructions du père se trouvent au case NbMax ?
 
2) À la sortie du switch, dans quel processus je me retrouve alors ?
 
3) Si tu bois pas de bière, tu bois quoi alors ?

1) fork renvoie une valeur non nulle (à savoir le pid du fils) uniquement quand on est dans le père, donc c'est le seul à rester dans la boucle, ce qui fait qu'à la fin i==NbMax.
 
2) Tous !
 
3) Du vin, du whisky, de la goutte... À peu près tout ce qui contient de l'alcool, en fait ;)

Étant donné que j'ai un nombre variable de processus mais qu'ils font presque tous la même fonction, est-ce que je peux faire :

 
 
Aussi, si j'envoie un signal SIGSTOP à un processus qui est en train de faire un tri, est-ce qu'il va continuer au même endroit quand je vais faire un SIGCONT ?

Aucun problème pour ces deux trucs.

Est-ce possible d'exécuter une fonction A lorsque j'envoie un signal SIGCONT du père au fils et une fonction B quand j'envoie un signal SIGCONT du fils au père ?
Exemple

Ou même, ne pas spécifier de fonction spécifique pour le fils et traiter le signal normalement.

Oui, ça devrait se faire.
Enfin, je suppose que tu voulais dire switch(i)...
 
Au passage, évite signal et utilise plutôt sigaction (c'est plus souple et ça évite certains problèmes).

Je comprends vraiment pas !

Ça donne ça
>Le fils s'endort. Pid = 12528
 Le pid du fils = 12528

et ça tombe en boucle infini. Est-ce que je dois rajouter qqchose ?

Tu viens de comprendre pourquoi on a inventé les sémaphores et les mutex.
 
Quand le père envoie SIGCONT, il est possible que le fils ne soit pas encore endormi...

Je peux pas croire qu'il ne le réveille jamais. La boucle fait que le père s'exécute à l'infini.

Tu as du mettre le père dans une autre boucle, alors... À moins que la fonction du père ne soit exécutée par erreur par un fils, sinon.

Là je comprends vraiment pas ce qui se passe.

 
J'ai essayé de simplifier le code, juste la base et ça ne marche pas !! Ça me fait comme résultat :
>toto
Le pere s'endort !
Le pere se reveille !
Le pere se rendort !
Le pere se reveille de nouveau !
 
C'est tout, aucun contact avec les processus fils ! Pourtant c'est pratiquement l'exemple du livre ! Je comprends vraiment plus rien !

[jfdsdjhfuetppo]--Message édité par Matheo--[/jfdsdjhfuetppo]

Normal, les processus fils sont morts, le programme terminé, puisque tu ne leur fais rien faire.

Ils devraient au moins afficher un message. Sinon, à quoi elle sert la fonction pause() ?

Est-ce qu'il y a moyen aussi de passer des paramètres à la fonction reliée au signal ?
Ex : signal(SIGINT, Fonction_A(parametre)) ;

Putain que je suis con ! Je suis con, je suis stupide, je ne mérite même pas de vivre !
 
Je viens de trouver LE bug qui faisait tout chier dans mon programme et maintenant ça marche impec. C'était tellement une erreur conne que j'en ai honte !
 
Y'a pas à dire, des fois je me surpasse au niveau de la connerie !