J'aimerais savoir si les appels système linux en lecture/écriture prennent en charge les lectures/écritures non synchronisées (écritures sans ajout) dans les régions sans chevauchement d'un seul fichier disque à partir de plusieurs threads ou processus. Chaque thread cherchera dans sa propre région du fichier et lira/écrira de/dans cette région exclusivement, sans jamais chevaucher les régions sur lesquelles les autres threads opèrent.
POSIX spécifie dans XSH 2.9.7 que pratiquement toutes les fonctions d'E/S sont atomiques les unes par rapport aux autres en ce qui concerne leurs effets spécifiés par POSIX. Une longue liste des fonctions spécifiques auxquelles cela s'applique est donnée, et open() , lseek() , read() , write() , et close() sont tous dessus. Par conséquent,
Si deux threads appellent chacun une de ces fonctions, chaque appel verra soit tous les effets spécifiés de l'autre appel, soit aucun d'eux.
Cela ne dépend d'aucune synchronisation externe, même pour des opérations sur des descripteurs de fichiers associés à une même description de fichier ouverte.
Il peut y avoir plusieurs descriptions de fichiers ouverts pour le même fichier, même dans un seul processus (voir, par exemple, la page de manuel pour open(2)). Étant donné plusieurs threads effectuant read() et write() opérations sur des régions non superposées d'un même fichier régulier, via des descripteurs de fichiers faisant référence à différentes descriptions de fichiers ouverts , POSIX ne fournit aucune base pour s'attendre à ce que ces opérations interfèrent les unes avec les autres, quelle que soit la synchronisation externe des threads impliqués. En pratique, cela fonctionne bien.
Où vous pouvez avoir des ennuis est si les threads impliqués essaient d'utiliser des descripteurs de fichiers faisant référence à la même description de fichier ouverte. Ceux-ci ne doivent pas nécessairement être la même valeur de descripteur de fichier (donc dup() un descripteur de fichier n'aide pas ici), et les threads ne doivent pas non plus appartenir au même processus pour que la situation se produise. Chaque description de fichier ouvert a une seule position de fichier associée, donc si deux threads différents essaient d'effectuer des tâches qui nécessitent chacune séparément définir l'offset de fichier et transférer des données vers ou depuis le fichier, et s'ils utilisent la même description de fichier ouvert, l'atomicité des appels de fonction individuels n'est pas suffisante pour garantir que les lectures et les écritures sont effectuées aux positions prévues. La synchronisation est requise dans ce scénario.
Alternativement, comme @maximegorushkin l'a observé dans les commentaires et @bk2204 l'a observé dans une autre réponse, le pread() et pwrite() fonctions effectuent le positionnement et le transfert de données en un seul appel. Celles-ci figurent également sur la liste des fonctions d'E / S atomiques et surmontent la séparation du positionnement du transfert de données sur une base de transfert de données par transfert. Leur utilisation nécessite des soins et une comptabilité supplémentaires, et il existe des scénarios qu'elle ne sert pas de manière adéquate, mais elle peut néanmoins être viable pour le cas particulier en question.
Par conséquent , si deux threads différents veulent opérer sur le même fichier sans synchronisation, l'approche la plus sûre et la plus générale consiste pour chacun à ouvrir le fichier indépendamment. Ils n'interféreront alors pas les uns avec les autres tant que leurs opérations d'E/S seront limitées à des régions disjointes du fichier. Même opérer sur des régions du fichier qui se chevauchent n'est pas hors de question, mais cela introduit des considérations plus complexes et spécifiques à l'application.
Oui, c'est possible. Le pread et pwrite Les fonctions vous permettent de lire et d'écrire à partir d'un fichier à un décalage donné sans modifier le décalage du fichier. Ils sont spécialement conçus pour permettre la lecture et l'écriture dans des programmes multithreads.
Vous devez noter qu'en violation de POSIX, pwrite sur un descripteur de fichier ouvert avec O_APPEND écrira toujours à la fin du fichier.