[C] FILE* et multithreading
Sauvegarde2
Messages postés
205
Date d'inscription
Statut
Membre
Dernière intervention
-
Char Snipeur Messages postés 9813 Date d'inscription Statut Contributeur Dernière intervention -
Char Snipeur Messages postés 9813 Date d'inscription Statut Contributeur Dernière intervention -
Bonjour,
Je fais du traitement de gros fichier optimisé avec pthread.
Le problème c'est que chaque thread accède au même fichier (une image hd en l'occurrence) en lecture donc modifie la position du curseur. et comme la mémoire est partagée ça plante.
Fournir une copie du FILE ou ré-ouvrir dans chaque thread le fichier ne me parait pas optimal.
Y'a t il une solution plus astucieuse pour ce genre de cas ?
Merci
Je fais du traitement de gros fichier optimisé avec pthread.
Le problème c'est que chaque thread accède au même fichier (une image hd en l'occurrence) en lecture donc modifie la position du curseur. et comme la mémoire est partagée ça plante.
Fournir une copie du FILE ou ré-ouvrir dans chaque thread le fichier ne me parait pas optimal.
Y'a t il une solution plus astucieuse pour ce genre de cas ?
Merci
A voir également:
- [C] FILE* et multithreading
- .Bin file - Guide
- Host file - Guide
- .Dat file - Guide
- Iso file - Guide
- File sdcard/dcim - Télécharger - Gestion de fichiers
4 réponses
Pourquoi ne pas utiliser des processus plutôt que des threads ?
Cela te permettra d'avoir un des espaces mémoires distinctes.
Après tout dépend aussi des opérations que tu fais sur le fichier. Lecture uniquement ?
Cela te permettra d'avoir un des espaces mémoires distinctes.
Après tout dépend aussi des opérations que tu fais sur le fichier. Lecture uniquement ?
Personnellement j'ai utiliser les multithreading une ou deux fois et a chaque fois je copiais listes chainées, ...
Ce que tu peux faire c'est utiliser la fonction pthread_mutex_lock() qui fait partie de la meme lib. Cela ne resoud pas tous les problemes mais ca permet de faire en sorte que quand un thread lit une info sur un espace memoire, les autres ne peuvent pas y acceder.
Le probleme : personnellement j'utilisais le multithread pour de l'affichage d'image et quand un thread ne peut pas utiliser une variable a cause de pthread_mutex_lock(), il ne fait rien et passe. Ce qui donnait une image avec des pixels noirs !
Bon courage. En cas de solution, je veux bien savoir ! ;)
Ce que tu peux faire c'est utiliser la fonction pthread_mutex_lock() qui fait partie de la meme lib. Cela ne resoud pas tous les problemes mais ca permet de faire en sorte que quand un thread lit une info sur un espace memoire, les autres ne peuvent pas y acceder.
Le probleme : personnellement j'utilisais le multithread pour de l'affichage d'image et quand un thread ne peut pas utiliser une variable a cause de pthread_mutex_lock(), il ne fait rien et passe. Ce qui donnait une image avec des pixels noirs !
Bon courage. En cas de solution, je veux bien savoir ! ;)
Pourquoi des threads ?
Justement parce que fork() duplique la mémoire dans le processus fils, une opération qui prend du temps. Quitte à faire des copies, autant ne copier que le stricte nécessaire.
Pour les mutex : il n'y a pas besoin de mutex ici puisque j'accède à la mémoire en lecture. Le seul soucis c'est que le simple fait de lire le fichier fait avancer le curseur et fausse la lecture des autres threads.
C'est d'ailleurs presque de la programmation quantique puisque l'on modifie ce qu'on observe :p
Justement parce que fork() duplique la mémoire dans le processus fils, une opération qui prend du temps. Quitte à faire des copies, autant ne copier que le stricte nécessaire.
Pour les mutex : il n'y a pas besoin de mutex ici puisque j'accède à la mémoire en lecture. Le seul soucis c'est que le simple fait de lire le fichier fait avancer le curseur et fausse la lecture des autres threads.
C'est d'ailleurs presque de la programmation quantique puisque l'on modifie ce qu'on observe :p
Bonjour,
Une idée : en fragmentant le fichier en plusieurs zones pour le charger en mémoire ? Comme pour une map énorme dans un jeu lorsque le joueur se déplace on ne charge en mémoire que les zones de la map entourant le joueur. Vu qu'il y a plusieurs "joueurs" chacun d'eux chargent les zones qui leur sont propres. Mais vu que le serveur ne peut pas physiquement recevoir plusieurs packets en même temps sur le même port, il traite le déplacement des joueurs chacun leur tour, ou en fonction de celui qui lag le moins, bref, un peu tordue comme idée.
Une idée : en fragmentant le fichier en plusieurs zones pour le charger en mémoire ? Comme pour une map énorme dans un jeu lorsque le joueur se déplace on ne charge en mémoire que les zones de la map entourant le joueur. Vu qu'il y a plusieurs "joueurs" chacun d'eux chargent les zones qui leur sont propres. Mais vu que le serveur ne peut pas physiquement recevoir plusieurs packets en même temps sur le même port, il traite le déplacement des joueurs chacun leur tour, ou en fonction de celui qui lag le moins, bref, un peu tordue comme idée.
je vois deux solution :
faire un seek dans les thread avant la lecture, mais pour peu que tu modifies aussi la position dans un autre thread entre les deux, tu es feinté.
ouvrir le fichier dans les thread, comme ça tu as un pointeur par thread et plus de problème.
Je ne vois vraiment pas comment tu pourrais faire pour partagé un seul pointeur entre tout les thread sans qu'il soit modifié.
faire un seek dans les thread avant la lecture, mais pour peu que tu modifies aussi la position dans un autre thread entre les deux, tu es feinté.
ouvrir le fichier dans les thread, comme ça tu as un pointeur par thread et plus de problème.
Je ne vois vraiment pas comment tu pourrais faire pour partagé un seul pointeur entre tout les thread sans qu'il soit modifié.