Bon je relance un sujet alors ! Je me suis un peu renseigné sur les threads en C. En fait j'ai un bon bouquin sur la programmation système Linux qui parle notamment de ça. Si j'ai bien compris, on crée un thread avec p_thread (ou qqchose comme ça je ne l'ai plus en tête la), et on associe une fonction à ce thread.

Cette fonction sera donc exécutée dans un processus différent en gros juste ?
Ma question est, est ce que le thread peut il utiliser d'autres fonctions du programme ? On associe une fonction de départ, mais est ce que à partir de cette fonction, on peut faire appel à d'autres fonctions du programme ?

Autre question, est ce qu'en tapant ctrl+c, cela va terminer le thread et donc rendre la main au processus père ?

Merci d'avance pour vos réponses !

Si je me souviens bien, les threads s'exécutent "en même temps" (enfin, c'est tellement rapide que ça revient à ça), et oui, tu peux utiliser d'autres fonctions du programme.
Et, non, la fonction n'est pas exécutée dans un processus différent, mais dans un thread différent. Elle partage donc un certain nombre de ressources avec le programme (je ne me souvient plus beaucoups, en fait, désolé, mais on est pas restés longtemps sur le multithread en cours, il est même probable que je dise des choses erronées ).
Pour ce qui est de rendre la main au thread principal, il me semble qu'il est possible de geler l'exécution du père en attendant la fin du fils, mais je ne me souvient pas de la fonction.

Ok..

Donc en gros je pourrais créer un thread comme suit :

phread_t newThread;

Et lui associer une fonction initiale comme suit :

pthread_create(newThread, pthread_attr_default, fonction_associée, argument)

Et donc ce serait la fonction_associée qui démarrerait le thread. Et dans cette fonction je pourrais utiliser les autres fonctions de mon programme alors... Pas trop compliqué à mettre en oeuvre...

Un thread partage les mêmes fonctions et les variables globales que le processus père. Seule la pile diffère.

Pour geler le processus père, la fonction est pthread_join de mémoire.

Attention toutefois, pour l'accés à des variables globales, il faut les protéger à l'aide de mutex, pour éviter qu'une variable ne soit modifiée par 2 threads différents en même temps (effets insoupsonné garanti). Pour cela, voir du coté des mutex.

attention avec les mutex:
si la thread 1 bloque les données A puis les B alors que la thread 2 fait pareil dans l'autre sens, bah il peut arriver que 1 attende que 2 débloque B alors que 2 attend que 1 débloque A ... et ça fige en squattant 0% du CPU ...

C'est vrai, mais tout dépend du protocole de gestion de ressources utilisés. Sans protocoles, cela peut se produire, mais avec un protocole comme le protocole à priorité plafond, les interblocages ne peuvent plus se produire.

Par contre, je ne sais pas si POSIX prévoit le choix du protocole, et en particulier de ce protocole...

même avec priorité, il faut toujours bien comprendre ce que fait le code dans les cas où la priorité joue. Il vaut mieux un truc ch**** qui refuse de marcher dès qu'il y a un pépin qu'un truc qui va lâcher le développeur dès qu'on passe un seuil critique d'erreurs.

Tout à fait d'accord. Et la priorité peut jouer sur le temps de réponse d'une tâche, c'est à dire entre le moment où elle démarre et le moment où elle se termine.

Le temps de réponse peut être critique, notamment sur des systèmes embarqués (avion, voiture, fusée, etc...), mais dans le cas de son utilisation, sur un processeur d'aujourd'hui, il n'y a aucun problème.

rapidement comme ça, c'est quoi les mutex ?

Mutex=Mutal Exclusion. Il s'agit en fait d'une valeur binaire, que l'on ne modifie que par des appels de fonction. Souvent, dans le jargon, on parle de prendre et vendre un mutex.

Pour prendre un mutex, il faut qu'il soit libre, c'est-à-dire qu'il n'a pas été pris avant. Pour libérer le mutex, lorsqu'une tâche l'a prise, on le "vend".

L'intéret des mutex est de protéger des zones critiques du code du proramme, par exemple, des zones où l'on accèdes à des variables globales. Ceci permet de s'assurer que des variables ne sont accéder que par une et une seule tâche en même temps, garantissant la validité des données.

Si une tâche essai de prendre un mutex déjà pris par une autre tâche, alors elle est bloquée et est mise dans une file d'attente. Lorsqu'une tâche libère son mutex, et s'il y a des tâches qui attendent le mutex, alors on prend une tâche de la file d'attente et on lui donne le mutex.

Si on utilise des mutex, et pas simplement des variables booléennes, c'est que les actions de "prendre" et "vendre", doivent être atomique, c'est-à-dire que de tels fonctions ne doivent pas être préemptée ou interrompue par l'execution d'une autre tâche. Ceci garantie l'intégrité des mutex et rend possible leur utilisation.

Il me semble que l'on peut également interdire l'interruption d'une tâche, pendant une zone d'exécution sensible...
Je ne sais plus comment on fait, mais je sais que c'est possibles