Discussion :

[ALEX77]

Bonjour

Je voudrais savoir si l'est techniquement possible d'avoir par exemple 10 threads travaillant sur le même handle de fichier.

On aurait en fait une seule variable f : file qui correspondrait au fichier à ouvrir (en lecture uniquement) et des threads qui utiliseraient ce handle pour lire le fichier mais à des positions différentes avec Seek(f, (position propre au thread) ), puis BlockRead(f,...)

N'y a-til pas un risque que le thread 1 lise le fichier mais à la position d'un autre thread ?

Faudrait-il alors créer autant de handles (f : array of file) qu'il y a de threads ?

Quelqu'un a-til déjà traité du multithreading sur un seul fichier ?

Merci pour vos idées

[ShaiLeTroll]

Effectivement, sans section critique, tu pourras avoir deux threads qui utilise Seek et se pertube mutuellement

Thread A Seek sur 100
Thread B Seek sur 200
Thread B Read sur 200 à 250
Thread C Seek sur 400
Thread A Read sur théoriquement 100 à 170 mais en réalité sur 400 à 475
Thread C Read sur théoriquement 400 à 500 mais en réalité sur 475 à 575

Donc soit un seul Handle avec une TCriticalSection protégeant contre le multi-Thread
Sinon utilise plusieurs TFileStream en lecture seule non exclusive, un par thread !
le Handle ou le TFileStream est un membre privé du Thread, n'utilise pas un tableau commun,
car lui aussi faudrait le protéger par une Section Critique pour gérer les Instanciations/Libérations

Personnellement, je l'ai fait, il y a des années mais en écriture, sans le faire vraiment exprès,
c'était une fonction qui écrivait dans un fichier log qui était utilisé un peu partout
Aujourd'hui, j'utilise plutôt une DB ou le journal Windows pour mes logs (et en cas d'ultime plantage de la DB, le fichier local)
Pour la version de Débogage, c'est un fichier local au lieu du journal Windows (lui semble parfaitement threadsafe)
j'ai au deux threads qui l'utilise en écriture, environ 10 écritures par seconde, j'ai parfois 2 écritures à la même milli-secondes
Par contre, même si cela ne plante pas, j'ai noté quelques très très rares chevauchements d'écriture (une ligne qui en a écrasé partiellement une autre)

Par contre, j'ai déjà fait de la lecture par plusieurs processus,
et je ne crois pas que cela change grand chose entre plusieurs processus ou plusieurs threads (si ces derniers sont correctement isolés)

[ALEX77]

Effectivement, j'avais un gros doute sur le tableau de handles aussi ; reste la solution au sein de chaque thread comme celle que tu proposes :

Sinon utilise plusieurs TFileStream en lecture seule non exclusive, un par thread !
le Handle ou le TFileStream est un membre privé du Thread

Merci pour ta réponse

[foetus]

Et pourquoi pas une file de messages protégée en écriture, sur le principe Consommateur/ Producteurs

Et ensuite le thread [fil d'exécution] "Consommateur" va écrire soit par lots (tous les X messages) (*) soit message par message.


* -> En cas de crashs il va y avoir des manques

[Andnotor]

Et pourquoi pas l'inverse : un thread principal pour la gestion du fichier (BlockRead compris) et des threads secondaires qui ne font que traiter les buffers (résultats des BlockRead). Ainsi plus besoin de synchro puisque plus d'accès concurrent

[tourlourou]

Si la taille du fichier le permet, pourquoi ne pas utiliser un TMemoryStream pour ouvrir le fichier en mémoire, et des descendants de TMemoryStream héritant chacun de la zone mémoire du premier, pour de la lecture uniquement (style TSharedMemoryStream) ?