[C] FILE* et multithreading
Fermé
Sauvegarde2
Messages postés
205
Date d'inscription
dimanche 14 décembre 2008
Statut
Membre
Dernière intervention
11 janvier 2015
-
18 juil. 2012 à 16:51
Char Snipeur Messages postés 9813 Date d'inscription vendredi 23 avril 2004 Statut Contributeur Dernière intervention 3 octobre 2023 - 1 août 2012 à 10:21
Char Snipeur Messages postés 9813 Date d'inscription vendredi 23 avril 2004 Statut Contributeur Dernière intervention 3 octobre 2023 - 1 août 2012 à 10:21
A voir également:
- [C] FILE* et multithreading
- Host file - Guide
- .Bin file - Guide
- .Dat file - Guide
- Swf file player - Télécharger - Lecture
- Iso file - Guide
4 réponses
fiddy
Messages postés
11069
Date d'inscription
samedi 5 mai 2007
Statut
Contributeur
Dernière intervention
23 avril 2022
1 842
18 juil. 2012 à 20:52
18 juil. 2012 à 20:52
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 ?
Utilisateur anonyme
19 juil. 2012 à 14:12
19 juil. 2012 à 14:12
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 ! ;)
Sauvegarde2
Messages postés
205
Date d'inscription
dimanche 14 décembre 2008
Statut
Membre
Dernière intervention
11 janvier 2015
261
19 juil. 2012 à 15:14
19 juil. 2012 à 15:14
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
Hxyp
Messages postés
401
Date d'inscription
vendredi 28 janvier 2011
Statut
Membre
Dernière intervention
27 avril 2014
54
1 août 2012 à 00:55
1 août 2012 à 00:55
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.
Char Snipeur
Messages postés
9813
Date d'inscription
vendredi 23 avril 2004
Statut
Contributeur
Dernière intervention
3 octobre 2023
1 298
1 août 2012 à 10:21
1 août 2012 à 10:21
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é.