[Threads/C] Fonction non bloquante checkant si un thread est fini...

Fonction non bloquante checkant si un thread est fini... [Threads/C] - C++ - Programmation

Marsh Posté le 14-09-2002 à 00:49:39    

Oui c'est encpore moi, et comme je change totalement de registre, ben je refais un post ;)
 
Donc, je dois gerer un nombre illimite de threads.
 
J'ai donc directement pense a une liste chainee...
 
Le probleme c'est que les threads sont geres sur commande via le reseau : Donc je peux en creer 5 d'un coup, attendre 15 ans,etc...
 
Pour simplifier, imaginez que je recois un signal du reseaul et la PAF je dois creer un thread pour faire une tache.
 
je cree une occurence dans la liste chainee, je cree le thread et je retourne attendre un signal du reseau.
 
Seulement, j'aimerai bien purger la liste chainee de tous les threads qui se sont deja termines de temps en temps...
 
Et la je ne sais pas comment faire :/
 
Avec pthreads_join, ca ne peux pas marcher, vu que ce dernier est bloquant...
 
En fait, me faudrait une fonction qui aille voir si un thread est fini ou non SANS attendre que celui ci se termine...
et ca je sais pas faire :/
 
Vous pouvez m'aider ? merci ;)


Message édité par Tetedeiench le 14-09-2002 à 00:55:32

---------------
L'ingénieur chipset nortiaux : Une iFricandelle svp ! "Spa du pâté, hin!" ©®Janfynette | "La plus grosse collec vivante de bans abusifs sur pattes" | OCCT v12 OUT !
Reply

Marsh Posté le 14-09-2002 à 00:49:39   

Reply

Marsh Posté le 14-09-2002 à 00:55:00    

pourquoi une thread qui se finit ne s'effacerait t'elle pas elle meme de la liste chainée ?
 
 
ou de signaler au pere par un qqconque moyen qu'elle a en a terminer avec son boulot ? (un vieux booleen, ou que sais-je)


Message édité par chrisbk le 14-09-2002 à 00:55:48
Reply

Marsh Posté le 14-09-2002 à 00:58:11    

parce que ca foutrait en l'air la liste chainee nan ?
 
Imagine je cree un thread. Je cree une occurence dans ma liste chainee, le thread se lance, et fait son job.
 
Je lance un second thread, une seconde occurence dans la liste chainee...
 
Ma liste chainee a donc sa tete pointant vers le premier thread, la queue pointant vers le second thread.
 
Comment tu veux qu'un thread modifie la structure de ma liste chainee... quand bien meme l'occurence dans ma liste chainee disparaissait, la tete pointera a ce moment la vers rien, et donc probleme :/
 
Je te montre ma liste chainee :
 

Code :
  1. typedef struct th_element{
  2.   pthread_t th;
  3.   struct th_element *next;
  4. }th_element;
  5. typedef struct{
  6.   th_element* head;
  7.   th_element* tail;
  8. }thread_list;
  9. thread_list th_list;


---------------
L'ingénieur chipset nortiaux : Une iFricandelle svp ! "Spa du pâté, hin!" ©®Janfynette | "La plus grosse collec vivante de bans abusifs sur pattes" | OCCT v12 OUT !
Reply

Marsh Posté le 14-09-2002 à 00:59:07    

chrisbk a écrit a écrit :

pourquoi une thread qui se finit ne s'effacerait t'elle pas elle meme de la liste chainée ?
 
 
ou de signaler au pere par un qqconque moyen qu'elle a en a terminer avec son boulot ? (un vieux booleen, ou que sais-je)
 




 
ah tiens, pas con, quand elle a fini, elle modifie sa propre structure pour dire "j'ai fini tu peux tout effacer sur moi"
 
Vraiment pas bete, c'est meme la solution je crois...


---------------
L'ingénieur chipset nortiaux : Une iFricandelle svp ! "Spa du pâté, hin!" ©®Janfynette | "La plus grosse collec vivante de bans abusifs sur pattes" | OCCT v12 OUT !
Reply

Marsh Posté le 14-09-2002 à 00:59:41    

bah pkoi ca la foutrait en l'air ? que ce soit la thread ou bien bien le processus pere qui joue avec la liste chainée ca change rien nan ?
par contre fodrait proteger de facon a ce que pas deux thread aille patauger dans la liste au meme moment

Reply

Marsh Posté le 14-09-2002 à 12:59:35    

fo juste penser à foutre un sémaphore pour éviter que deux threads qui modifient la liste chainée l'explosent...
 
du style, deux threads modifient deux "entrées" consécutives de la liste chainée, si pas sémaphore => bouzillage des pointeurs (suivant/précédent)

Reply

Marsh Posté le 14-09-2002 à 13:08:08    

18h

bjone a écrit a écrit :

fo juste penser à foutre un sémaphore pour éviter que deux threads qui modifient la liste chainée l'explosent...
 
du style, deux threads modifient deux "entrées" consécutives de la liste chainée, si pas sémaphore => bouzillage des pointeurs (suivant/précédent)




 
Tout a fait exact => c'est ce que tu dois faire !

Reply

Marsh Posté le 14-09-2002 à 17:11:58    

bjone a écrit a écrit :

fo juste penser à foutre un sémaphore pour éviter que deux threads qui modifient la liste chainée l'explosent...
 
du style, deux threads modifient deux "entrées" consécutives de la liste chainée, si pas sémaphore => bouzillage des pointeurs (suivant/précédent)



vi vaut mieux protéger tout ca par des mutex histoire de pas tout nicker


Message édité par joce le 14-09-2002 à 17:12:40

---------------
Protèges carnets personnalisés & accessoires pour bébé
Reply

Marsh Posté le 14-09-2002 à 19:16:01    

Pour répondre a la question, même si ca te sert plus a rien, c'est la fonction WaitForSingleObject qu'il faut utiliser (sous Windows).
Et sinon une petite question qui me trotte dans la tête depuis longtemps :
c'est quoi la différence entre un mutex et un semaphore (ou plutôt c'est quoi un mutex?)


---------------
FAQ fclc++ - FAQ C++ - C++ FAQ Lite
Reply

Marsh Posté le 14-09-2002 à 19:48:23    

HelloWorld a écrit a écrit :

Pour répondre a la question, même si ca te sert plus a rien, c'est la fonction WaitForSingleObject qu'il faut utiliser (sous Windows).
Et sinon une petite question qui me trotte dans la tête depuis longtemps :
c'est quoi la différence entre un mutex et un semaphore (ou plutôt c'est quoi un mutex?)



un mutex c'est un semaphore binaire :sol:


---------------
"OCPLB : On Casse Pas Le Binôme, 'moiselle Jade, Carlson & Peters, page 823 !"
Reply

Marsh Posté le 14-09-2002 à 19:48:23   

Reply

Marsh Posté le 14-09-2002 à 21:17:41    

chrisbk a écrit a écrit :

bah pkoi ca la foutrait en l'air ? que ce soit la thread ou bien bien le processus pere qui joue avec la liste chainée ca change rien nan ?
par contre fodrait proteger de facon a ce que pas deux thread aille patauger dans la liste au meme moment



Le plus prudent serait peut être que les threads n'aillent pas patauger dans cette liste.
Pourquoi pas tout simplement faire en sorte que le thread qui se termine positionne un flag (dans l'entrée qui lui correspond dans la liste) ?
De temps en temps, le père regarde les éléments qu'il peut supprimer, qui correspondent à des threads terminés.


Message édité par mrbebert le 14-09-2002 à 21:18:15
Reply

Marsh Posté le 14-09-2002 à 22:35:10    

bjone a écrit a écrit :

fo juste penser à foutre un sémaphore pour éviter que deux threads qui modifient la liste chainée l'explosent...
 
du style, deux threads modifient deux "entrées" consécutives de la liste chainée, si pas sémaphore => bouzillage des pointeurs (suivant/précédent)



Pas mieux. :jap:


---------------
Le site de ma maman
Reply

Marsh Posté le 16-09-2002 à 12:35:37    

si tu fait un ptrhead_setcancelstate (pour enabler/dissabler la fonction le flag de fin) puis un pthread_test_cancel sa doit fonctionner


---------------
la théorie c quant tout dois fonctionner mais rien ne marche                                 la pratique c quant tout marche mais personne ne c pourquoi                           ici on fais un bon compromis rien ne marche et personne ne c pourquoi :D
Reply

Marsh Posté le 16-09-2002 à 15:19:29    

Tetedeiench a écrit a écrit :

Oui c'est encpore moi, et comme je change totalement de registre, ben je refais un post ;)
 
Donc, je dois gerer un nombre illimite de threads.
 
J'ai donc directement pense a une liste chainee...
 
Le probleme c'est que les threads sont geres sur commande via le reseau : Donc je peux en creer 5 d'un coup, attendre 15 ans,etc...
 
Pour simplifier, imaginez que je recois un signal du reseaul et la PAF je dois creer un thread pour faire une tache.
 
je cree une occurence dans la liste chainee, je cree le thread et je retourne attendre un signal du reseau.
 
Seulement, j'aimerai bien purger la liste chainee de tous les threads qui se sont deja termines de temps en temps...
 
Et la je ne sais pas comment faire :/
 
Avec pthreads_join, ca ne peux pas marcher, vu que ce dernier est bloquant...
 
En fait, me faudrait une fonction qui aille voir si un thread est fini ou non SANS attendre que celui ci se termine...
et ca je sais pas faire :/
 
Vous pouvez m'aider ? merci ;)




 
Sur n'importe quel OS multi tache, tu as déjà une liste chainée gérant les threads et effaçant bien sûr ceux qui ne s'éxécute plus...(Si tu cherche un thread précis, en général, le header de chaque thread contient le thread parent).
 
Bref, je comprends pas pourquoi tu les mets dans une liste...Tu as un traitement à faire dessus?


---------------
Horizon pas Net, reste à la buvette!!
Reply

Marsh Posté le 17-09-2002 à 03:08:10    

Willyzekid a écrit a écrit :

 
 
Sur n'importe quel OS multi tache, tu as déjà une liste chainée gérant les threads et effaçant bien sûr ceux qui ne s'éxécute plus...(Si tu cherche un thread précis, en général, le header de chaque thread contient le thread parent).
 
Bref, je comprends pas pourquoi tu les mets dans une liste...Tu as un traitement à faire dessus?




 
non, mais j;ai besoin d'un thread par client, et j'ai deja une liste chainee de client car il peut y en avoir un nombre illimite ( relatif aux capacites de la becane of course).


---------------
L'ingénieur chipset nortiaux : Une iFricandelle svp ! "Spa du pâté, hin!" ©®Janfynette | "La plus grosse collec vivante de bans abusifs sur pattes" | OCCT v12 OUT !
Reply

Marsh Posté le 17-09-2002 à 08:51:44    

à la limite tu prends le source de mysql et tu regardes :D


---------------
Protèges carnets personnalisés & accessoires pour bébé
Reply

Marsh Posté le 17-09-2002 à 10:44:25    

ben le mieux c'est encore d'avoir un thread central qui est appelé par les threads a la fin de leur exécution.
C'est uniquement ce thread qui nettoie quand il est appelé (ou bien de tant en temps comme un garbage collector)
Comme ca tu centralises le traitement et ton pere ben il peut faire autre chose !

Reply

Marsh Posté le 17-09-2002 à 11:29:56    

Le probleme n'est il pas plus profond ?
 
Es-ce bien raisonnable de gerer un nombre infini de threads ?
 
tu pred pas mal de ressources sytemes en creant/detruisant des threads...

Reply

Marsh Posté le 17-09-2002 à 13:35:08    

pourquoi pas utiliser pthread_cont_timedwait qui bloque le mutex en attendant qu'il soit réveillé par un pthread_cond_signal ou pthread_cont_broadcast, mais également qui retourne une erreur en cas de timeout du thread ?
 
SYNOPSIS  
#include <pthread.h>  
 
int pthread_cond_timedwait(pthread_cond_t *cond, pthread_mutex_t *mutex, const struct timespec *abstime);  
 
pour convertir des secondes en abstime tu fais :
 
set_timespec(abstime, ton_temps_en_secondes);
 
et
 
#define set_timespec(ABSTIME,SEC) { (ABSTIME).ts_sec=time(0) + (time_t) (SEC); (ABSTIME).ts_nsec=0; }
 
voire (si t'as pas la structure ts)
 
#define set_timespec(ABSTIME,SEC) \
{\
  struct timeval tv;\
  gettimeofday(&tv,0);\
  (ABSTIME).tv_sec=tv.tv_sec+(time_t) (SEC);\
  (ABSTIME).tv_nsec=tv.tv_usec*1000;\
}


---------------
Protèges carnets personnalisés & accessoires pour bébé
Reply

Marsh Posté le 17-09-2002 à 14:31:32    

Je comprends pas le prb :)
Ok pour une liste de client mais pourquoi une liste de thread? Quel intéret pour toi de faire de la microgestion et de les stocker?


---------------
Horizon pas Net, reste à la buvette!!
Reply

Marsh Posté le 17-09-2002 à 15:39:42    

Prenons le cas d'un fonctionnement sous UNIX. A chaque mort ou terminaison de ton processus, le père sera mis au courant et saura quel processus est mort. Par conséquent, tu peux mettre à jour ta liste chainée. Meme chose pour des threads.
 
a+


---------------
Setiseur de pingouin :D
Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed